APIs Are the New Perimeter
Every modern SaaS is an API with a frontend bolted on. Your mobile app, your web app, your integrations — they all talk to the same REST or GraphQL API. And attackers know this.
The OWASP API Security Top 10 has become more relevant than the original OWASP Top 10 for SaaS products. Here are the 5 risks I encounter most often during penetration tests.
1. Broken Object-Level Authorization (API1:2023)
What it is: An API endpoint returns data based on a user-supplied ID without checking if the requesting user owns that resource.
Real example: GET /api/invoices/1452 returns invoice #1452. But the user from Company A changes the ID to 1453 and receives Company B's invoice — complete with billing address, VAT ID, and line items.
The fix: Never trust the object ID from the URL. Every database query must include the user's tenant/ownership context. Pseudocode:
// Wrong
SELECT * FROM invoices WHERE id = $url_id;
// Correct
SELECT * FROM invoices WHERE id = $url_id AND tenant_id = $session_tenant_id;
2. Broken Authentication (API2:2023)
What it is: Weak or missing authentication on API endpoints, or authentication that's easy to bypass.
Real example: An admin endpoint at /api/admin/users checks for a valid JWT — but accepts tokens signed with algorithm none or with an empty secret. Or worse: the staging environment has the same JWT secret as production, hardcoded in a .env.example file committed to the public repo.
The fix:
- Whitelist JWT algorithms (only RS256/HS256, never
none) - Rotate secrets between environments
- Add rate limiting to login and token refresh endpoints
3. Broken Object Property Level Authorization (API3:2023)
What it is: The API accepts more fields in the request body than intended. Mass assignment lets users set fields they shouldn't.
Real example: A "Update Profile" endpoint accepts POST /api/users/me with a JSON body. The backend blindly updates every field in the request:
{
"name": "Attacker",
"role": "admin",
"plan": "enterprise",
"is_verified": true
}The fix: Whitelist allowed fields. Never use $model->update($request->all()). Always explicitly list which fields can be updated:
$user->fill($request->only(['name', 'avatar', 'timezone']));4. Unrestricted Access to Sensitive Business Flows (API6:2023)
What it is: API endpoints that perform business-critical actions without abuse protection.
Real example: A "Refer-a-Friend" program gives both users a $10 credit. No rate limiting, no duplicate checking. One attacker writes a script that creates 1,000 fake accounts and collects $10,000 in credits.
The fix: Model the business impact of API abuse. If an endpoint moves money, credits, or access — add rate limiting, duplicate detection, and anomaly monitoring.
5. Server-Side Request Forgery (API7:2023)
What it is: The API accepts a URL as input and makes a request to it. Attackers use this to hit internal services.
Real example: A webhook registration endpoint takes https://example.com/webhook and the server verifies the URL is reachable. An attacker provides http://169.254.169.254/latest/meta-data/ (AWS metadata endpoint) and receives AWS credentials in the response.
The fix: Never let user-supplied URLs reach internal IP ranges. Use a URL allowlist when possible. Block requests to 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16, and 127.0.0.0/8.
---
The Pattern
Notice the pattern in all 5 risks? Trust boundaries. Your API trusts the client to send the right IDs, the right fields, the right URLs. Attackers exploit that trust.
Every API endpoint should ask: "Is the entity making this request authorized to access the resource this request targets?" If the answer isn't an unambiguous yes, you have a vulnerability.
What's Missing from This List?
Injection (SQLi, NoSQLi) and security misconfiguration are still common — but they've been pushed down by modern frameworks with built-in parameterization and secure defaults. The risks above are the ones frameworks don't solve for you. Authorization is your responsibility.