- API breaches cost $591,000 on average—$832,800 in financial services—and 99% of organizations experience one within a year.
- 54% of attacks exploit security misconfiguration (API8), and 52% of breaches stem from broken authentication; both are preventable with pre-launch testing.
- A security audit before shipping catches broken access controls, missing rate limits, and unencrypted endpoints—the gaps that cost 20% more to fix post-breach.
An API security audit is a systematic review of your API's authentication, authorization, data handling, and configuration before it goes live. Most founders skip it because they ship with internal testing and assume production will be fine. It won't. 99% of organizations experienced API security problems in the past 12 months, with 34% involving sensitive data exposure. The gaps that get exploited are not exotic. They're the ones this checklist catches.
Why Pre-Launch Matters (The Numbers)
Fixing an API vulnerability after launch costs exponentially more than catching it before. API breach costs exceed $591,000 on average—with financial services incidents costing $832,800 per event. API-related breaches cost up to 20% more than traditional breaches due to broader data access. Conversely, companies with strong API security practices save an average of $1.76 million per breach.
The attack surface is growing. The average number of daily API attacks per organization rose 113% year over year from 2024 to 2025. And the attacks are precise. 95% of attack attempts coming from authenticated sources underscores the growing risk of insider threats, compromised accounts, and attackers leveraging stolen credentials.
If your API moves money, health data, or customer identity, the cost of waiting until after launch isn't measured in engineering time. It's measured in regulatory fines, customer churn, and reputation damage. For financial services, there's also the 72-hour GDPR breach notification window.
The Three Layers of Pre-Launch Audit
Layer 1: Authentication & Token Expiry
52% of API breaches in 2025 were caused by broken authentication, and 59% of API vulnerabilities require no authentication at all. Before you ship, verify:
- Every endpoint that touches data requires authentication. No "public read" exceptions unless explicitly intentional and documented.
- JWT tokens expire within 15 to 60 minutes. Refresh tokens should have a maximum lifetime of 7 to 30 days.
- Token validation happens on every request, not just the first. Revoked tokens actually block access within seconds.
- Tokens are never logged, cached, or exposed in error messages.
- API keys (if used) are rotated, tied to environments, and rate-limited per key.
Test this: use an expired token and a revoked token. Both should return 401. Use no token at all. Expect 401, not 200.
Layer 2: Authorization & Broken Access Control (BOLA)
Authentication says "you are who you claim." Authorization says "you can access this." Broken Object Level Access (BOLA) is the second-most exploited gap. BOLA testing requires using User A's token to request objects belonging to User B — expecting a 403 or 404, not a 200.
Before launch, test:
- User A logs in, copies their auth token, and tries to fetch User B's account, order, or document. Response should be 403 (Forbidden) or 404 (Not Found). Never 200 OK with data.
- A user with read-only permissions tries to update or delete. Expect 403.
- A guest (or low-tier user) tries to access admin endpoints. Expect 401 or 403.
- Pagination and filtering parameters don't let users bypass ownership checks (e.g., `/orders?user_id=999` as a regular user should not work).
- IDs in URLs are validated against the user's own data. Never trust the client to send the right ID without server-side verification.
Layer 3: Configuration & Data Protection
API8 (Security Misconfiguration) accounts for 54% of attacks, making it the most exploited vulnerability. This is the checklist most teams forget, and attackers rely on it.
- HTTPS is enforced on all endpoints. HTTP requests should redirect or be rejected, not accepted.
- CORS headers are explicit. `Access-Control-Allow-Origin: *` is never acceptable for production APIs. Whitelist specific domains.
- HTTP headers are set: `X-Content-Type-Options: nosniff`, `X-Frame-Options: DENY`, `Strict-Transport-Security`, and `Content-Security-Policy` if serving browser-accessible content.
- Error messages don't leak system details. A 500 error should say "error processing request," not "NullPointerException at line 42 in UserService.java."
- Logging doesn't capture passwords, tokens, credit card numbers, or PII. Sensitive data is masked before it hits logs.
- Rate limiting is configured per endpoint and per user. `/login` should allow 5 attempts per 15 minutes. `/search` might allow 100 per minute.
- API documentation doesn't list credentials, API keys, or internal IPs. Public docs should describe behavior, not implementation.
- Unused endpoints are removed. A legacy `/admin/debug` endpoint that's no longer needed is still a door.
- Input validation rejects oversized requests, malformed JSON, and unexpected field types. Set max payload sizes.
- SQL injection, command injection, and XXE are tested. Use parameterized queries, never string concatenation for database calls.
Pre-Launch Audit Checklist
| Category | Test | Pass Criteria | Priority |
|---|---|---|---|
| Authentication | Expired token request | 401 response, no data | Critical |
| Authentication | No token request | 401 response | Critical |
| Authentication | Invalid signature on JWT | 401 response | Critical |
| Authorization | User A accesses User B's data | 403 or 404, never 200 | Critical |
| Authorization | Guest user accesses admin endpoint | 403 response | Critical |
| Authorization | Read-only user updates data | 403 response | Critical |
| Configuration | HTTPS enforced | HTTP requests rejected or redirected | Critical |
| Configuration | CORS headers explicit | No `*` wildcard, specific domains listed | High |
| Configuration | Security headers present | X-Content-Type-Options, X-Frame-Options, HSTS | High |
| Configuration | Error messages sanitized | No stack traces, line numbers, or file paths | High |
| Configuration | Rate limiting active | 429 response after limit, per-user and per-endpoint | High |
| Configuration | Sensitive data not logged | Tokens, passwords, PII masked in logs | High |
| Data Handling | SQL injection attempt | Rejected or safely escaped | Critical |
| Data Handling | Oversized payload | 413 or 414 response, request rejected | High |
| Data Handling | Malformed JSON | 400 response | High |
When to Hire a Third Party
If your API handles payment data, health information, or user identity, bring in an external security auditor. They'll test and document findings in a report you can show regulators, investors, or customers. If your API is internal-only or a prototype, you and your team can run through the checklist above. If you're shipping to thousands of users in a regulated industry (financial services, healthcare, automotive), hire external. The 4-6 week window before launch is the time to do it.
Authect includes a security audit in every project—authentication and authorization testing, configuration review, and compliance checks for GDPR, HIPAA, or PCI-DSS where relevant. We catch these gaps during development, not after shipping.
FAQ
Do I need a security audit if my API is only for internal use?
Internal APIs are still targets. 95% of attack attempts coming from authenticated sources underscores the growing risk of insider threats, compromised accounts, and attackers leveraging stolen credentials. A disgruntled employee or a compromised account can still cause damage. Run through the checklist above at minimum. External audit depends on data sensitivity.
What's the difference between security misconfiguration and broken authentication?
Broken authentication means the login or token system itself is flawed (expired tokens not invalidated, weak token expiry). Security misconfiguration means the API is set up in an unsafe way (HTTPS not enforced, CORS headers too permissive, error messages leaking data). Both are in the top exploited vulnerabilities. API8 (Security Misconfiguration) accounts for 54% of attacks, so this one is often neglected.
How long does an API security audit take?
A focused internal checklist (the table above) takes 2–3 days if your team is trained. An external audit by a specialized firm takes 1–2 weeks depending on API complexity. If you're shipping within 4–6 weeks, start the audit by week 2 so findings can be fixed before launch.
What do I do if the audit finds a critical vulnerability?
Don't ship. Fix it, re-test, and re-audit. GDPR breach notifications must be made within 72 hours. If you launch with a known critical gap and it's exploited, you're notifying users, regulators, and customers within 72 hours. That costs more than delaying launch by two weeks.
