The three-layer trap in API security
By Sayed Ashraful Islam Sakib.
Originally published on LinkedIn. Text, publication date, and post link are taken from the live post.
Baseline controls, perimeter defenses, and the deep defenses against CSRF and stored XSS that checklists tend to miss.
The post
The 3-Layer Trap: Why Most Developers Stop Short of Real API Security
Most of us treat API security like a checklist. We lock the front door—rate limiting, CORS, parameterized queries—and call it done. The windows and back doors stay wide open.
Here’s what we miss.
THE STANDARD
Rate limiting, CORS, and injection prevention are baseline. They’re not wrong. They’re just the start. And per-IP rate limiting isn’t enough: botnets spread traffic across thousands of IPs. You need an overall rate limit too—a circuit breaker for the whole system when individual limits are bypassed.
THE PERIMETER
A WAF catches unknown attack patterns and suspicious traffic before it hits your API. Internal tools (admin dashboards, debug endpoints) shouldn’t be on the public internet. Put them behind a VPN or private network. “It’s internal” isn’t a security control. “It’s not on the internet” is.
THE DEEP DEFENSE
Session cookies alone invite CSRF: a malicious site can trigger requests with the user’s cookies. You need CSRF tokens. And a “harmless” comment section can become stored XSS—malicious scripts in your DB, running in every visitor’s browser. Sanitize. Escape. Treat user content as hostile.
The ask: audit the hidden stuff. Do we have a global fail-safe? What’s actually in front of our API? Where do we trust user input into the DOM or into cookie-authenticated requests? Find those windows and back doors. Then close them.
What’s one “hidden” vulnerability you’ve found (or fixed) in an API you work on?