Secure by design incorporates security concerns from API design through implementation, testing, deployment, and operations. It shifts security left, shortening the feedback loop so teams find design flaws before architectural decisions become expensive to change. section 1.2 section 1.5
APIs expose data and functionality, so every parameter, user flow, and response can become an attack surface. Secure design considers how attackers could abuse legitimate-looking requests, then constrains inputs, protects sensitive data, and prevents unsafe business behaviors before release. section 1.0 section 6.1
Apply the approach across the API lifecycle:
- Design safe user flows, document the API accurately, involve stakeholders, and assess exposed parameters, sensitive data, and access controls. section 1.2.1 section 3.1
- Use secure implementation patterns, including parameterized database queries, strict validation, separate input and output models, and protection against mass assignment. section 1.8 section 6.5
- Test continuously with specification checks, fuzzing, end-to-end tests, and automated access-control tests before moving to the next stage. section 1.5 section 3.1
- Operate securely with detailed logs, user-activity monitoring, threat detection, restrictive network controls, API gateways, and WAFs. section 1.5 section 1.2.3
Constrain pagination and payment input
An e-commerce GET /products endpoint should not accept unrestricted page sizes: a request for 100 million items could overwhelm servers. A secure specification bounds page and perPage values. Similarly, POST /payments should accept only amount and currency through a strict MakePayment model, rather than reusing an output model containing status. Otherwise, a caller might submit status: settled and attempt to set a server-side property. section 6.1 section 6.5
Figure 1.4 In the traditional approach to API security, we wait until deployment to run our tests and discover vulnerabilities. We typically discover hundreds of vulnerabilities, and we have to go back to the beginning of the process multiple times to address them. With security by design, we address security in every step of the development cycle and, therefore, have fewer surprises when we run the tests after deployment.
Compare late vulnerability discovery with security checks applied throughout the development cycle. section 1.2
For legacy APIs, obtain an API specification first, even if it must be generated from code or traffic. Use the specification to expose unknown attack surfaces, test design assumptions, and track whether each failed security check is resolved before deployment. section 1.2.1 section 2.5
