What are the different approaches to API Security?

1. API Security by Design
   In this approach, an API is properly defined and documented in an API contract (using the OpenAPI/Swagger specification). This contract acts as a single source of truth and has many uses, e.g. as the design for the API itself, provide clear specifications for front-end and backend teams,  integration purposes and most importantly, be used for API security testing and protection. More information on why the API contract matters.
   Key benefit: The benefit of adopting this approach is that the API contract becomes the foundation for the entire API security lifecycle.  This ensures that everyone involved in the SDLC (developers, testers, operations, and security teams) works from one authoritative document, eliminating inconsistencies between design, implementation, and documentation.
2. Pre-Production API Security Testing
   Both the API and API Contract can be tested for conformance in the IDE by the development team and continuous automation of this testing can be enforced in the CI/CD pipeline by security teams. Testing is conducted for the OWASP API Top 10 vulnerabilities such as BOLA/BFLA and injection paths.
   Key benefits:  By identifying and fixing issues earlier, companies reduce the potential for vulnerabilities ever reaching production. Remediating issues in pre-production is significantly cheaper and faster than patching them post-deployment. Developers also get immediate feedback inside their IDE, encouraging secure coding habits, resulting in faster releases of production-ready API-based services.
3. Runtime API Threat Protection
   Once an API is pushed into production, the API is protected by only permitting requests that are specifically defined in the API contract (API Protection). Any change to the API contract will automatically update the API Protection configuration, affording continuous real-time threat protection. Using API Protection from 42Crunch, security teams can automatically detect and block real-time exploits and abuse such as BOLA/BFLA, token replay, scraping, injection, mass assignment, and misused endpoints. When the contract changes, enforcement updates automatically—delivering continuous, real-time protection without manual tuning. This capability is unique to 42Crunch and enables us to deliver API security at the speed of development without any delays to enforcement.
   Key Benefits: Adopting this approach ensures that your APIs are protected in real time against the OWASP API top 10 risks and many others besides. Suspicious or non-compliant traffic is automatically blocked before it reaches the API backend. Traditional Web Application Firewalls (WAFs) require constant tuning and manual rule updates to handle evolving APIs. 42Crunch’s approach automates this process by regenerating protection rules directly from the API contract and this drastically reduces operational overhead and minimizes false positives/negatives.
4. API Anomaly detection, API Behavior monitoring and API Discovery
   • API discovery identifies APIs in your estate—including shadow/rogue endpoints—often by analysing network and gateway traffic.
   • API behavior monitoring observes how APIs are used over time to establish a baseline of “normal” requests and responses.
   • API anomaly detection uses statistical models and ML/AI (increasingly including LLMs) to flag deviations from that baseline that may indicate misuse or attack.

   The challenge with these solutions is that they are notoriously difficult to install and often require time to establish baseline of traffic to the API in order to make observations. Furthermore, they need to be reconfigured every time a change to an API is made, which impacts their efficacy and poor user experience.  When these anomaly detection tools actually identify unusual patterns, they typically flag them to a 3rd party SIEM but they lack the  contextual awareness of what the API should expect and are unable to determine what to permit or block. Such systems are always reactive, and cannot block zero day attacks, and oftentimes rely on integrations with third party products, such as API gateways, to actually block traffic.
   For a deeper dive, see our in-depth API security versus Anomaly Detection whitepaper below.

5. API DAST testing (Dynamic Application Security Testing)
   The answer is in the name. Application security testing. These tools have been successful at testing applications by sending large amounts of prebuilt generic tests to the application. These tools were needed for application testing as there is no recognized specification for the application like there is for APIs. APIs usually have explicit specifications (e.g.,OpenAPI), rich business rules, and context-dependent behavior. Generic black-box probing struggles without that context.
   In our own evaluation against a deliberately vulnerable API, a DAST tool executed 12,000 tests and found none—because it couldn’t infer what the API was supposed to do or validate behavior against the spec. As API security has become an increasing problem, these providers promise to solve API security with the same tool they run application security testing with, but the bottom line is that it doesn’t work. DAST may occasionally catch issues, but it won’t secure your APIs on its own. Effective API security needs context-aware, policy-driven testing and enforcement throughout the lifecycle (design, build, and runtime).
   Read our analysis on the differences between API security testing and DAST