API Security: What I would do with 30 minutes a week

The talk starts from a practical limit: an API security program may get only about 30 minutes a week. The speakers argue that teams tend to fix whatever is urgent instead of building a steady routine, so they present a short, prioritised list of basic measures rather than a strategic overview. They note that many recent API-layer breaches came from simple gaps, such as an endpoint that was locked down one day and open the next, rather than from sophisticated attacks.

The core is a ranked set of checks. First, review which APIs became reachable overnight and scan the open ones for personal data with a basic PII tool. Next come secrets left in code repositories or publicly shared Postman collections, and retiring unused endpoints that have gone untouched for long periods. Authentication and encryption follow: move off basic auth and old TLS versions, and score APIs against those baselines. Later items cover watching for sudden traffic surges, filtering low-reputation source addresses, flagging unusually large data downloads, removing rarely needed methods such as DELETE, and keeping regular testing for object-level authorization and SSRF.

The closing argument is that a security operations team, not only application security engineers, should own the daily routine, since they already work with alerts and telemetry. Measuring results with simple metrics keeps the work from being ignored. In the Q&A, the speakers acknowledged that operations staff often lack API vocabulary, so reports need to be simplified and someone has to build them. The main takeaway is to start with a daily report of APIs that changed from closed to open.