The Big Question
What happens when your API endpoint that returns data by ID doesn't check if the caller is authorized to see that specific object? What if an unauthenticated developer endpoint is left exposed to the internet, or an API key with full admin permissions is hardcoded in a public repository?
Modern applications are built on APIs, and one misconfiguration can expose millions of records. This guide covers the essential practices to secure your APIs against the attacks that actually happen.
1. Authentication and Authorization: The Foundation
The Core Principle: Trust Nothing
Every request to a protected endpoint must be authenticated and authorized. The two concepts are distinct:
-
Authentication: Verifies who the caller is.
-
Authorization: Verifies what the caller is allowed to do.
A common and critical failure is Broken Object Level Authorization (BOLA), which is the #1 API risk according to OWASP. This occurs when an endpoint fetches a resource using an ID from the request but fails to verify that the authenticated user owns or has permission to access that specific resource.
A practical example: An API endpoint that fetches invoice details by ID. Without object-level checks, an authenticated user could request invoices belonging to other customers simply by changing the ID parameter. The caller is authenticated, but unauthorized to access that specific resource.
Best Practices
Enforce Object-Level Authorization: Always scope data lookups to the authenticated user. When a user requests a resource by ID, ensure the query explicitly includes the user's identity as a filter. Never trust a client-provided ID to imply authorization.
Use the Principle of Least Privilege: Grant the minimum permissions needed for each role or scope. A reporting dashboard doesn't need write access to user records. Use Role-Based Access Control (RBAC) or Attribute-Based Access Control (ABAC) to enforce permissions consistently.
Authenticate Properly:
-
Prefer Short-Lived Tokens: For user-facing APIs, use OAuth 2.0 bearer tokens (like JWTs) over static API keys. This limits the value of a leaked credential. Pair short access tokens with refresh token rotation.
-
Validate JWTs Strictly: When using JWTs, pin the accepted algorithm explicitly (e.g.,
RS256), verify the signature, and check expiration, not-before, issuer, and audience claims on every request. Never accept a token's self-declared algorithm. -
For Service-to-Service: API keys are acceptable if handled correctly. This means each key is scoped to specific operations, tied to one client, rotatable, and stored as a hash on the server. Never put keys in URLs, as they will end up in server logs.
-
Mutual TLS (mTLS): For high-value internal or partner APIs, use mTLS to authenticate the client at the transport layer before your application logic even runs.
2. Input Validation and Rate Limiting
Validate All Input
Input validation stops injection attacks (SQL, NoSQL) and business logic exploits.
-
Use Allowlists: Define what is accepted rather than trying to block every possible malicious input.
-
Use Schema Validation: Enforce request structure consistently across endpoints using schema validation libraries. Validate the type, length, and format of every field.
-
Sanitize Output: Encode data before including it in responses to prevent Cross-Site Scripting (XSS) attacks.
Implement Rate Limiting and Throttling
Without rate limits, your API is vulnerable to brute-force attacks, credential stuffing, and denial-of-service (DoS) attacks.
-
Layer Your Limits:
-
Backend protection: Limit per API key or consumer (e.g., 1000 requests/second) to protect your services from overload.
-
Attack mitigation: Limit per IP or token with much lower thresholds (e.g., 10-50 requests/second) to slow down scripted attacks.
-
Endpoint-Specific Limits: Apply stricter limits to sensitive endpoints like login and password reset flows.
-
-
Return Proper Headers: When a client exceeds the limit, return a
429 Too Many Requestsstatus with aRetry-Afterheader.
3. OWASP API Security Top 10: Your Coverage Map
The OWASP API Security Top 10 is the primary checklist for API security. Use it as a coverage map for your security reviews.
| Risk | Description | Key Mitigation |
|---|---|---|
| API1:2023 | Broken Object Level Authorization (BOLA) | Enforce object-level checks for every request. Never trust a client-provided ID to imply authorization. |
| API2:2023 | Broken Authentication | Validate JWTs fully, use short-lived tokens, and rate-limit auth endpoints. |
| API3:2023 | Broken Object Property Level Authorization | Validate which properties a user can access or modify (e.g., prevent mass assignment). |
| API4:2023 | Unrestricted Resource Consumption | Implement rate limiting, cap page sizes, and enforce request body size limits. |
| API5:2023 | Broken Function Level Authorization | Check user roles server-side on every privileged function, not just in the UI. |
| API6:2023 | Unrestricted Access to Sensitive Business Flows | Protect critical flows (e.g., buying, transferring money) that need more than simple rate limits. |
| API7:2023 | Server Side Request Forgery (SSRF) | Validate and sanitize any URLs the API fetches. |
| API8:2023 | Security Misconfiguration | Ensure debug mode is off, error messages are sanitized, and CORS is configured properly. |
| API9:2023 | Improper Inventory Management | Document and secure all API endpoints. Deprecate old versions with a timeline and enforce end-of-life. |
| API10:2023 | Unsafe Consumption of APIs | Treat data from third-party APIs as untrusted. Validate the response schema and treat URLs as SSRF candidates. |
4. The API Gateway Security Baseline
Your API gateway is the single point of entry for all API traffic. Its misconfiguration is now one of the highest-leverage attack surfaces.
-
Default-Deny Policy: The non-negotiable starting point is that every route requires authentication unless explicitly carved out (e.g., login endpoints, health checks). Flip the default.
-
Schema Validation at the Gateway: Enforce OpenAPI or GraphQL schemas at the gateway. This catches injection and mass-assignment vulnerabilities before they reach your backend. Treat the schema as the source of truth and ensure it's updated with every release.
-
Observability Without Leaking Secrets: Gateway logs are essential for incident response, but they shouldn't leak credentials. Implement structured logging with explicit allowlists for fields that get captured. Headers like
authorization,x-api-key, andcookieshould be redacted by default. -
Gateway Supply Chain: Treat the gateway like any other production service. Generate an SBOM, scan for vulnerabilities, and keep it updated.
5. Practical Do's and Don'ts
| Do This | Don't Do This |
|---|---|
| Use HTTPS everywhere. | Store passwords in plain text. |
| Implement strong authentication (JWT, OAuth 2.0). | Use weak secrets. |
| Validate all user inputs. | Trust user input. |
| Use parameterized queries or an ORM to prevent SQL injection. | Expose stack traces in error messages. |
| Hash passwords with bcrypt (salt rounds >= 10). | Use string concatenation for SQL queries. |
| Implement rate limiting and throttling. | Store sensitive data in JWTs. |
| Use short-lived tokens (JWT access tokens expire quickly). | Ignore security updates. |
| Log security events and monitor for suspicious activity. | Log sensitive data (like tokens and PII). |
Implementation Roadmap
Phase 1: Foundation (Weeks 1-4)
-
Audit your API inventory: Document every endpoint. Identify which are public, partner-facing, or internal.
-
Assess authentication controls: Ensure every protected endpoint requires authentication and implements object-level checks.
-
Establish rate limiting: Start with conservative limits and tune based on traffic patterns.
-
Set up API gateway security: Enable default-deny and schema validation.
Phase 2: Hardening (Weeks 5-8)
-
Implement least privilege: Review and restrict permissions for all roles and API keys.
-
Validate input schemas: Ensure every endpoint enforces request validation.
-
Enable logging: Implement structured logging with PII redaction.
-
Test OWASP coverage: Run security reviews against the OWASP Top 10.
Phase 3: Governance and Monitoring (Weeks 9-12+)
-
Establish a deprecation policy: Define timelines and security requirements for API version retirement.
-
Monitor for anomalies: Set up alerts for unusual traffic patterns or access attempts.
-
Schedule regular reviews: Conduct quarterly security assessments of API estate.
Frequently Asked Questions
Q1: What is the OWASP API Security Top 10?
It's a community-maintained list of the ten biggest security risks for APIs, published by OWASP. The 2023 version moved authorization risks to the top, reflecting where real-world breaches happen most.
Q2: What is the most critical API security risk?
Broken Object Level Authorization (BOLA) is now ranked #1. It's the failure where a request reaches data the caller is not allowed to see. It is trivial to introduce and invisible in a happy-path test.
Q3: What is the difference between authentication and authorization?
Authentication verifies who the caller is. Authorization verifies what the caller is allowed to do. A request is authenticated but unauthorized if the caller doesn't have permission.
Q4: How can I manage API inventory effectively?
Every API should have an OpenAPI or GraphQL schema in the repository. Every deployment should register itself with a service catalog. Use external attack-surface management tools to catch what your catalog misses.
Q5: How can Innovative AI Solutions help?
We help organizations design, implement, and operationalize API security programs from threat modeling and authentication hardening to gateway configuration and governance frameworks. Based in Delhi, serving clients across India.
Final Thought
The most common API breaches aren't sophisticated. They're predictable failures in authentication, authorization, and rate limiting. By adopting a baseline approach rooted in the OWASP Top 10 and NIST guidelines, organizations can close these gaps and build APIs that are resilient against the attacks that actually occur.
Contact Us:
Phone: +91 7464 099 059 / +91 9689967356
Email: info@innovativeais.com
Address: Netaji Subhash Place, Pitampura, Delhi – 110034
Website: https://innovativeais.com
About the Author
Abhishek Kumar
Founder & CEO, Innovative AI Solutions
5+ years building AI, cloud, and enterprise systems. Based in Delhi, serving clients across India.
