These questions arise when someone discovers the OWASP API Security Top 10 2023 (released June 5, 2023), and their team is already deploying new endpoints. They're trying to understand what "Broken Object Level Authorization" means for their upcoming code review.
I've been in those Slack threads. The questions are practical, sometimes urgent, and rarely align with formal documentation. Here's what people actually ask.
Q: Do I really need to check authorization on every single API call?
Yes, and specifically at the object level.
API1:2023 Broken Object Level Authorization isn't about whether someone's logged in. It's about whether user 42 can access order 1337 just because they know the endpoint is /api/orders/1337. Your authentication middleware doesn't solve this.
Check authorization in every function that touches a data source using a user-supplied ID. That means:
- Before you query the database
- Before you return the object
- Before you modify it
- Before you delete it
If you're using an ORM, wrap your queries with ownership checks. If you're writing raw SQL, add AND user_id = ? to your WHERE clauses. Never assume possession of an ID equals permission to access it.
Q: We're getting hammered by credential stuffing. Is that in the Top 10?
API2:2023 Broken Authentication covers this, but the category is broader than just password attacks.
Common authentication failures include:
- No rate limiting on login endpoints
- Tokens that don't expire (or expire in 30 days)
- Password reset flows that leak account existence
- API keys in URLs or logs
- Accepting tokens after logout
Fix rate limiting first. If you're seeing credential stuffing, you don't have effective rate limits. Add per-IP and per-account limits on authentication endpoints. Then audit your token lifecycle: generation, storage, validation, and revocation.
Q: What's the difference between API3 and API1? They both say "authorization"
API3:2023 Broken Object Property Level Authorization is about what fields someone can see or modify within an object they can access.
API1 is: can user A access order B?
API3 is: if user A can access order B, can they see the internal_cost field or modify the status field?
This is why "Excessive Data Exposure" and "Mass Assignment" are combined now. Both stem from not validating authorization at the property level.
Practical fix: use different response schemas for different roles. Don't return a user object with 47 fields and hope your frontend only displays the safe ones. Return only the fields this caller is authorized to see. For updates, explicitly allowlist which fields can be modified, don't just bind the entire request body to your model.
Q: How do I know if we have API9 problems? We don't even know all our APIs
Start with API9:2023 Improper Inventory Management by asking three questions:
- Can you list every API version currently running in production?
- Can you list every deprecated endpoint that's still accessible?
- Do you know which APIs are externally facing vs. internal?
If you answered no to any of these, you have an inventory problem.
Build your inventory:
- Check your API gateway or load balancer configs
- Scan your repositories for OpenAPI/Swagger specs
- Review your DNS records for api.* subdomains
- Check your CI/CD pipelines for deployment targets
Then document: version numbers, deprecation dates, authentication requirements, and data sensitivity. You can't secure what you can't enumerate.
Q: We call a bunch of third-party APIs. Do we need to validate their responses?
API10:2023 Unsafe Consumption of APIs says yes, and here's why: attackers compromise your system by going after the third-party services you trust.
You're probably validating user input. You're probably not validating responses from your payment processor, your email service, or your analytics API.
Treat third-party API responses like user input:
- Validate response schemas before using the data
- Set timeouts on all external calls
- Don't trust HTTP status codes alone
- Sanitize any third-party data before storing or displaying it
- Log anomalies in third-party responses
If your payment API suddenly returns an order total of -$1000, your code should catch that before processing the refund.
Q: Our APIs are behind a VPN. Do we still need to worry about API7?
API7:2023 Server Side Request Forgery happens even behind VPNs, and it's worse there because your internal services probably trust each other.
If your API accepts a URL from a user (webhook URL, image to fetch, document to import), you need SSRF protection:
- Allowlist permitted domains or IP ranges
- Block requests to private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
- Block requests to localhost and metadata services (169.254.169.254)
- Validate and sanitize URLs before making requests
The VPN protects against external attackers. SSRF protection defends against attackers who've already compromised one service using it to pivot to others.
Q: What's the fastest win for a team that's done nothing?
API8:2023 Security Misconfiguration, specifically: turn off debug endpoints in production.
Check right now:
- Is your
/debugor/adminendpoint accessible? - Are stack traces being returned to clients?
- Is CORS set to
*? - Are default credentials still active?
- Is your API documentation publicly accessible when it shouldn't be?
These are configuration changes, not code rewrites. You can fix them this week.
Where to go from here
The OWASP API Security Project documentation breaks down each category with attack scenarios and prevention measures. The stable 2023 version is your current reference.
But here's what the documentation won't tell you: you can't fix all ten categories simultaneously. Pick the two that match your actual threat model. If you're seeing authentication attacks, start with API2. If you're shipping endpoints faster than you can track them, start with API9.
Security standards work when you implement them incrementally, not when they sit in a bookmarked tab you'll "get to eventually."
