API Security Best Practices: How to Protect Your Business Data in 2026

APIs are the nervous system of modern software. Every time a user logs in, makes a payment, retrieves their data, or connects a third-party tool, an API call is handling it. Which means every one of those interactions is also a potential attack surface.

API security incidents have increased sharply in recent years. The 2023 T-Mobile breach exposed 37 million customer records through an API endpoint with no rate limiting. The 2022 Optus breach in Australia exposed 9.8 million customer records through an unauthenticated API accessible from the public internet. These were not sophisticated nation-state attacks. They were basic API security failures that any competent development team could have prevented.

This guide covers the foundational API security practices that every business operating a web application, mobile app, or third-party integration should have in place in 2026. For a full security audit of your application, see our cybersecurity service and our companion post on cybersecurity for small business.

Why API security requires its own focus

Traditional web application security focused on the browser-facing layer: preventing XSS in rendered HTML, protecting form submissions, hardening web servers. APIs introduced a fundamentally different attack surface. For broader context on securing your business, see our cybersecurity guide for small business, and for API integration that is built with security controls from the start, our engineering team can help.

APIs expose functionality directly, often without the authentication and validation layers that web applications evolved to include. They are accessible to any client, not just a browser. They are designed to be machine-readable, which means automated scanning and enumeration is trivial. And they frequently expose sensitive business logic and data more directly than a rendered web page ever did.

The OWASP API Security Top 10 project exists specifically because the traditional OWASP Top 10 did not adequately address the API-specific threat landscape. Understanding the OWASP API Top 10 is the starting point for any serious API security review.

OWASP API Security Top 10 explained

1. Broken Object Level Authorization (BOLA)

BOLA is the most common and impactful API vulnerability. It occurs when an API endpoint accepts an object identifier from the client (such as a user ID, document ID, or order ID) without verifying that the authenticated user is authorised to access that specific object.

Example: GET /api/orders/12345 returns the order for any authenticated user, not just the user who owns order 12345. An attacker can enumerate order IDs to access every customer's order history.

Fix: Implement object-level access checks on every endpoint that returns a resource. Verify that the authenticated user has permission to access the specific object being requested, not just that they are authenticated.

2. Broken Authentication

Weak authentication implementations allow attackers to impersonate legitimate users. Common failures include weak JWT signing secrets, no token expiry, missing rate limiting on authentication endpoints, and accepting tokens signed with the none algorithm.

Fix: Use short-lived access tokens (15 to 60 minutes) with refresh tokens. Sign JWTs with a strong secret or asymmetric key pair. Rate-limit authentication endpoints. Reject tokens with weak or missing signatures.

3. Broken Object Property Level Authorization

This vulnerability occurs when an API endpoint returns more data than the client should see (excessive data exposure) or allows clients to modify properties they should not have access to (mass assignment).

Example: A user profile endpoint returns the user's hashed password and internal admin flags alongside their name and email. A user registration endpoint allows clients to submit is_admin: true alongside their registration data.

Fix: Use explicit allowlists (DTOs or serialisers) for what each endpoint returns and accepts. Never pass raw database objects directly to API responses.

4. Unrestricted Resource Consumption

APIs without rate limiting are vulnerable to denial of service attacks and resource exhaustion. Without limits, a single client can make millions of requests that overwhelm your database, inflate your cloud costs, or degrade performance for legitimate users.

Fix: Implement rate limiting at the API gateway or application layer. Define request rate limits per user, per IP, and per endpoint. Set maximum payload sizes. Implement pagination on endpoints that return collections.

5. Broken Function Level Authorization

Some API endpoints perform privileged actions (deleting records, modifying other users' data, accessing admin functions) that should be restricted to admin roles. Broken function level authorization occurs when these endpoints are accessible to lower-privilege users because the role check is missing or incorrectly implemented.

Fix: Document every privileged action your API performs. Implement role-based access control (RBAC) checks at the function level, not just at the object level. Audit admin endpoints in penetration tests specifically.

6. Unrestricted Access to Sensitive Business Flows

Some business flows (placing orders, creating accounts, applying coupon codes) have business logic that depends on them not being automated at scale. An attacker who can script these flows at thousands of requests per second can abuse them: exhausting inventory, generating fraudulent credits, or overwhelming capacity.

Fix: Implement device fingerprinting, CAPTCHAs, or rate limiting on sensitive business flows. Monitor for unusual patterns (sudden spike in orders from a single IP, account creation at machine speed) and implement anomaly detection.

7. Server Side Request Forgery (SSRF)

SSRF occurs when an API endpoint accepts a URL from the client and makes a server-side request to that URL. An attacker can supply internal network addresses to probe your internal infrastructure, access cloud metadata endpoints (which often expose credentials), or pivot to internal services not accessible from the internet.

Fix: Validate and allowlist permitted domains for any URL input. Disable redirects. Block requests to private IP address ranges. Use a separate network egress path for user-initiated fetches.

8. Security Misconfiguration

The most common API security issue in practice is misconfiguration: default credentials, unnecessary endpoints exposed, overly permissive CORS headers, missing security headers, verbose error messages that expose stack traces or database schemas, and unnecessary HTTP methods enabled.

Fix: Remove or disable all endpoints not required for production. Implement a strict CORS policy that allowlists only known origins. Add security headers (Content-Security-Policy, X-Frame-Options, Strict-Transport-Security). Return generic error messages in production.

9. Improper Inventory Management

Shadow APIs and zombie APIs (endpoints from previous API versions that were never removed) are consistently the most surprising finding in API security audits. Teams forget these endpoints exist. Attackers scan for them systematically.

Fix: Maintain a complete, up-to-date API inventory. Retire deprecated endpoints promptly. Version your API explicitly and provide a deprecation timeline to API consumers. Use an API gateway that provides endpoint visibility.

10. Unsafe Consumption of APIs

Your application is only as secure as the third-party APIs it integrates with. Blindly trusting and rendering data from external APIs without validation or sanitisation introduces vulnerabilities.

Fix: Validate and sanitise all data received from third-party APIs before using it in your application. Do not trust redirects from external APIs. Apply the same security controls to API responses as you do to user input.

Practical API security implementation guide

Authentication and authorisation

Use OAuth 2.0 or OpenID Connect for user authentication. Do not implement your own token system if a well-vetted standard exists. Libraries like Auth0, Okta, and AWS Cognito handle the complex parts of token management correctly by default.

Use API keys for machine-to-machine authentication. Generate cryptographically random keys of at least 256 bits. Store hashed versions in your database, not the raw key. Scope keys to specific permissions and endpoints.

Implement JWT correctly.

• Use RS256 (asymmetric) rather than HS256 (symmetric) if multiple services need to verify tokens
• Set a short exp (expiry) claim: 15 minutes for access tokens, 7 to 30 days for refresh tokens
• Set the aud (audience) claim to prevent tokens issued for one service being used on another
• Validate every claim: exp, iss, aud, and sub at minimum

Transport security

All API traffic must use HTTPS. In 2026, there is no acceptable justification for a production API serving unencrypted HTTP.

Additional transport controls:

• Enforce TLS 1.2 at minimum; prefer TLS 1.3
• Use HTTP Strict Transport Security (HSTS) with a long max-age
• Implement mutual TLS (mTLS) for high-trust machine-to-machine connections
• Rotate TLS certificates automatically using Let's Encrypt or a managed certificate service

API key management

API key sprawl is one of the most common security failures in organisations that integrate with multiple services. Controls to implement:

• Store all API keys in a secrets manager (AWS Secrets Manager, HashiCorp Vault, Google Secret Manager) rather than in environment variables or source code
• Rotate keys on a schedule (quarterly minimum for high-value integrations)
• Audit API key usage and revoke unused keys
• Never commit API keys to version control. Use a pre-commit hook that scans for credential patterns

Rate limiting and throttling

Implement rate limiting at the API gateway layer so it applies uniformly regardless of the application server handling the request.

Recommended limits for most applications:

• Unauthenticated endpoints: 10 to 20 requests per minute per IP
• Authentication endpoints: 5 attempts per 15 minutes per IP, with exponential backoff after failures
• Authenticated endpoints: 100 to 1,000 requests per minute per user, depending on use case
• Resource-intensive endpoints (reports, exports): stricter limits of 5 to 10 per minute

Logging and monitoring

API security without monitoring is security theatre. If you cannot detect an attack in progress, you cannot respond to it.

Log at minimum:

• All authentication events: success, failure, token refresh, logout
• All authorisation failures (access denied events)
• All requests to admin and privileged endpoints
• Anomalous request patterns: high frequency from a single source, sequential ID enumeration, error rate spikes

Set up alerts for: authentication failure rate spikes, unusual request volumes, access to endpoints from unexpected geographic regions, and 4xx error rate spikes on authenticated endpoints.

API security for teams without a dedicated security team

Small and mid-sized businesses operating web applications typically do not have a dedicated security team. If you want a specialist, you can hire a security engineer offshore or engage our cybersecurity service for a structured audit. Practical steps that fit a lean team without dedicated security support:

1. Run OWASP ZAP or Burp Suite Community against your own API before each major release
2. Require security review as part of your code review process for any new endpoint
3. Use a managed API gateway (AWS API Gateway, Kong, Apigee) that handles rate limiting, authentication, and logging out of the box
4. Subscribe to CVE notifications for every open-source library your API depends on
5. Commission an annual penetration test from a qualified security firm, even a brief one targeting the OWASP API Top 10

An offshore development team with security expertise can instrument your API with logging, implement rate limiting and proper authentication, and run automated scanning as part of a regular security cadence at a fraction of the cost of a local security specialist.

The cost of securing an API correctly during development is a fraction of the cost of recovering from the breach that results from not doing it. Fix your authentication, implement object-level authorisation, add rate limiting, and start logging. That alone eliminates the majority of API breaches in the wild. Our custom software development team builds APIs with these controls in place from the start, and our DevOps for startups guide covers the infrastructure hardening layer that complements application-level security.