An API exposes business capabilities and information to consumers. API security protects those assets by reducing the risk that weaknesses in the API can be exploited. It is not a single design check: security work continues through design, development, testing, and runtime operation. section 10.2.1 section 8.11.6
Start by identifying what could be harmed. Threat modeling considers possible threats, their likelihood and impact, and the controls that could reduce the risk. A vulnerability is a weakness an attacker can exploit; an attack is an attempt to carry out a threat. Relevant controls include encryption, authentication, authorization, audit logging, and rate-limiting. section 10.2.1
Put checks where they can inform the next decision:
- At design time, lint API definition files with security-focused rules. Include the check in a pull-request build so designers can address detected issues early. Keep secure-design guidance in the API style guide. section 8.11.6 section 10.0
- In a deployment pipeline, an API security platform can scan definitions and enforce a quality gate. For example, a 42Crunch GitHub Action scores each definition from 0 to 100; configure a minimum passing score and inspect its linked report. section 8.11.6
- In nonproduction testing, dynamically test application APIs for vulnerabilities and business-logic attacks. In production, monitor traffic for threats and take corrective action when an attack is identified. section 10.2.14
Review an insecure API proposal
Suppose you are asked to review an OpenAPI proposal for a car-service API before it is built. The intentionally insecure OWASP crAPI definition, `chapter10/crapi.api.yaml`, is a practice artifact: examine its design for security defects rather than treating a successful lint run as proof that the running service is safe. Follow design findings with testing and runtime checks as the API moves through delivery. section 10.2 section 10.2.1 section 10.2.14
Design scans can flag issues in authentication, authorization, transport, and payloads, but they address only the definition. Runtime monitoring addresses a different surface and can also help identify undocumented shadow APIs and deprecated zombie APIs still operating. Choose controls across the life cycle rather than relying on one score or one scan. section 8.11.6 section 10.2.14
