OWASP

In the previous post, ZAP gave us automated coverage against a running API, probing for common vulnerability patterns in requests and responses. There is an entire category of risk that scan never touches, because it does not live in API behavior at all. It lives in what dependencies a service pulls in, and what a commit accidentally includes. This closing post in the OWASP series covers both. Why Dependency Scanning Is Its Own Category Every Spring Boot service pulls in dozens, often hundreds, of transitive dependencies, and any one of them can have a known vulnerability disclosed after you first added it. A service can pass every API test and every ZAP scan cleanly while still shipping a logging library with a critical, publicly known remote code execution flaw. Nothing about API level testing catches this, because the vulnerability is not in your code’s behavior, it is in a jar sitting in your classpath. ...

The last two posts covered specific, hand written test cases for BOLA, broken authentication, and excessive data exposure. Those tests are precise and fast, but they only catch what you thought to write a test for. OWASP ZAP, the Zed Attack Proxy, takes a different approach, actively probing an API for a much broader set of known vulnerability patterns automatically. This post covers wiring it into a pipeline as a regression gate, and just as importantly, how to keep it from becoming noise nobody reads. ...

In the previous post, we focused entirely on BOLA and object ownership checks. This post covers two more categories from the OWASP API Security Top 10 that tend to show up together in practice, broken authentication and excessive data exposure. Both are less about a single missing check and more about a general habit of trusting the client too much. Broken Authentication: Token Expiry A surprising number of APIs issue tokens correctly but never quite get around to enforcing their expiry properly. Testing this directly is simple once you have a way to generate an expired token. ...

In the previous post, we walked through why the OWASP API Security Top 10 deserves attention from a QE team directly, not just a security specialist. Broken Object Level Authorization sits at the top of that list, and for good reason. It is one of the easiest vulnerabilities to introduce by accident, and one of the easiest to test for once you know to look. What BOLA Actually Is BOLA happens when an API checks that a user is authenticated, but does not check that the authenticated user is actually allowed to access the specific object they are requesting. The classic example, a transaction history endpoint. ...

Most testers have at least heard of the OWASP Top 10, the well known list of the most critical web application security risks. Fewer have spent real time with its sibling list, the OWASP API Security Top 10, which exists because APIs fail in ways that are genuinely different from traditional web applications, and a checklist built for server rendered pages with form submissions misses most of what actually goes wrong in a REST API sitting behind a mobile app or a partner integration. ...