Most QA teams test API functionality thoroughly but treat security as a separate, manual, and late-stage activity — when they test it at all. The result is predictable: critical vulnerabilities are only discovered during occasional audits, far removed from the development cycle where they would be cheaper to fix.

This presentation explores how to integrate the OWASP API Security Top 10 into the regular testing cycle, turning risks such as Broken Object Level Authorization (BOLA), broken authentication, and excessive data exposure into automated, repeatable checks. Drawing on real-world cases, we will explore the most critical risks in the Top 10, with concrete examples of exploitation and, more importantly, detection. We will demonstrate how tools QA professionals already know — Postman and automation frameworks such as Playwright — can address a significant proportion of these risks without requiring a dedicated security specialist or additional budget.

The central theme is mapping each OWASP item to the exact point in the pipeline where it should be tested: what functional tests can validate, what requires a dedicated security test, and what can — and should — run automatically with every build. The goal is practical: to equip API testers with a set of techniques they can start applying the following Monday, demonstrating that security testing is not a separate discipline, but a natural extension of QA work. Attendees will leave the session with a clear, actionable roadmap — not just an abstract list of threats.