Why Your API Is Probably Misconfigured
The five API misconfigurations we end up exploiting in almost every single engagement.
By ProteQon Red Team
Most of the APIs we test aren't brought down by exotic zero-days. They're brought down by configuration — defaults left on, controls assumed but never enforced. These are the five misconfigurations we end up exploiting in almost every engagement.
1. Authorization assumed at the gateway, enforced nowhere
Teams put authentication at the edge — an API gateway or a login check — and assume that means the request is authorized. Authentication answers “who are you”; authorization answers “are you allowed to touch this.” We constantly find authenticated-but-unauthorized access because the per-object check was never written.
2. CORS set to reflect any origin
Access-Control-Allow-Origin reflecting the request’s Origin while also sending Access-Control-Allow-Credentials: true is a gift. It lets a malicious site read authenticated responses on behalf of a logged-in victim. We test by sending an arbitrary Origin and checking whether it’s echoed back with credentials allowed.
Origin: https://attacker.example
Access-Control-Allow-Origin: https://attacker.example
Access-Control-Allow-Credentials: true3. No rate limiting on sensitive actions
Login, password reset, OTP verification, and coupon redemption are frequently unthrottled. Missing rate limits turn a 6-digit OTP into a 10-minute brute force and let us enumerate valid accounts at will. Rate limiting belongs on actions, not just on raw request volume.
4. Verbose errors and exposed debug surfaces
Stack traces, SQL fragments, internal hostnames, and live /actuator, /debug, or Swagger endpoints in production hand attackers a map of your stack. We grep responses for version strings and internal paths before we even start attacking logic.
5. Mass assignment and over-permissive payloads
APIs that bind request JSON straight onto a model accept fields you never intended — isAdmin, role, account_id, verified. If the server doesn’t explicitly allow-list writable fields, assume an attacker will write the ones you forgot.
Fixing the class, not the instance
- Enforce authorization per object, server-side, behind a single policy layer.
- Lock CORS to an explicit allow-list of trusted origins; never reflect Origin with credentials.
- Rate-limit authentication and other sensitive actions by account and by IP.
- Strip debug endpoints and verbose errors from production builds.
- Allow-list writable fields on every create and update endpoint.
None of these are hard. They're just easy to skip when you're shipping fast — which is exactly why we find them every time.