Stații de lucru

API Security Testing in CI/CD

• Data 10/09/2026
• Autor Costin Dumitru
• 6
• 212

Since you already work with pentesting tools like Burp Suite, Metasploit, and Nikto, think of this as extending that manual mindset into an automated, repeatable pipeline stage. The goal of CI/CD-integrated API security testing is to catch vulnerabilities like broken authorization or injection flaws on every code change, not just during periodic audits.

Testing an API before it reaches production is far cheaper than fixing it after deployment, especially for issues like Broken Object Level Authorization (BOLA) or Broken Function Level Authorization (BFLA), which are the top risks in the OWASP API Security Top 10 2023. The core idea of “shift-left” is simple: generate and lint your OpenAPI specification, run authorization and fuzzing tests automatically, scan infrastructure-as-code for misconfigurations, and fail the build when high-severity issues appear.

Given your background in penetration testing, here’s a question to get you thinking before we go further: when you manually test an API for BOLA today, what steps do you take to confirm one user can’t access another user’s data? Hold that thought, because we’re about to automate exactly that.

CI/CD API security testing generally falls into three buckets, each targeting a different class of OWASP API risks:

• Authentication and authorization tests — verifying BOLA (swap object IDs between two valid users), BFLA (replay admin-only requests with a lower-privilege token), mass assignment (attempt to modify read-only fields via POST/PATCH), and token lifecycle behavior (expired or revoked tokens must return 401, not stale cached data).

• Input and request validation tests — submitting oversized payloads, SQL/NoSQL/command injection strings, path traversal attempts, malformed JSON/XML, and checking that GraphQL endpoints enforce query complexity limits and disable introspection in production.

• Transport and configuration tests — enforcing HTTPS everywhere, validating TLS versions and cipher suites, checking security headers, testing CORS against unauthorized origins, and scanning for verbose debug output that leaks internal paths.

A practical automation pattern for BOLA/BFLA, drawn from real testing workflows, looks like this: extract every route from your OpenAPI spec to build your attack surface list, capture three token sets (admin, standard user, unauthenticated), then programmatically replay the same request while swapping tokens or object IDs between the two user accounts — if a low-privilege token or wrong user’s ID returns a 200 instead of 403/404, you’ve found a flaw.

Building the Pipeline Stage

Rather than treating a security scan as an afterthought, it should run as a pipeline job that blocks deployment on critical findings, similar to how you might already gate deployments on failed unit tests. A minimal GitHub Actions-style stage would download a scanner such as the OWASP API Security Testing Framework, point it at your API with an auth token, output results in a machine-readable format like SARIF, and upload that report to your code scanning dashboard so findings show up alongside pull requests. Tools like OWASP ZAP, Burp Suite (which you already use manually), and 42Crunch can run these scans directly against your OpenAPI/Swagger spec, meaning your existing spec becomes the test target instead of something you write test cases for by hand.

Beyond deployment-triggered scans, it’s worth scheduling separate recurring scans (weekly or monthly) against your live production API, since configuration drift — like a firewall rule change or an expired cert — can introduce vulnerabilities between deployments even without a code change. NIST’s guidance on API protection for cloud-native systems frames this as two complementary layers: static definition-time protections (defining schemas, valid value ranges, and maintaining an API inventory) and runtime protections applied to every request and response, including encryption in transit, authentication/authorization checks, and rate limiting or circuit breaking.

Prioritizing What to Automate First

If you’re setting this up from scratch, the recommended order is: start with authorization testing (BOLA, then BFLA), then authentication, then input validation and rate limiting, then configuration and API inventory checks. A condensed priority view looks like this:

Given your Rocky Linux and Kubernetes experience, you’re well positioned to containerize a scanner like ZAP or the OWASP ASTF as a pipeline job that spins up, hits a staging deployment, and tears down automatically.

To check your understanding: if a CI/CD pipeline scan finds that a standard-user token can successfully call an admin-only /users/delete endpoint, which OWASP risk category does that fall under, and what specific pipeline check would you add to catch it on every future pull request?