API security best practices for modern applications
Why API security matters
APIs are the connective tissue of modern software. They link your mobile app to your backend, your frontend to your data, your systems to your partners, and your business to cloud services. The average organisation exposes dozens - sometimes hundreds - of API endpoints.
This proliferation creates a large and growing attack surface. Unlike traditional web applications, APIs often lack a visible user interface, which means security flaws are less obvious and more easily overlooked. An API that returns too much data, accepts unvalidated input, or lacks proper authentication is a vulnerability waiting to be exploited.
The numbers reflect this reality. API attacks have grown year on year, and OWASP now maintains a dedicated API Security Top 10 alongside its traditional web application list. For South African businesses building digital products, securing APIs is not optional - it’s foundational.
Authentication: proving who’s calling
Every API request must be authenticated. The mechanism depends on the context:
API keys
Simple to implement, API keys identify the calling application. They’re appropriate for low-sensitivity, server-to-server integrations. However, API keys are static secrets - if leaked, they grant access until rotated. Never embed API keys in client-side code, mobile apps, or public repositories.
OAuth 2.0
The industry standard for delegated authorisation. OAuth allows a client application to access resources on behalf of a user without handling their credentials directly. It supports multiple grant types for different scenarios: authorisation code flow for web apps, client credentials for service-to-service, and PKCE for mobile and single-page applications.
JSON Web Tokens (JWT)
JWTs are commonly used as bearer tokens in API authentication. A JWT contains encoded claims (user identity, roles, expiry) signed by the issuer. The API validates the signature and checks claims before granting access.
Best practices for JWT:
- Use short expiry times and refresh tokens.
- Validate the signature, issuer, audience, and expiration on every request.
- Never store sensitive data in the JWT payload - it’s encoded, not encrypted.
- Use asymmetric signing (RS256) over symmetric (HS256) for production systems.
Integrating API authentication with a centralised identity and access management platform ensures consistent policies across all your services.
Authorisation: controlling what’s allowed
Authentication proves identity; authorisation determines what that identity can do. Common API authorisation failures include:
- Broken object-level authorisation - a user accesses another user’s data by changing an ID in the request (e.g.,
/api/orders/1234to/api/orders/5678). The API must verify that the authenticated user owns or is permitted to access the requested resource. - Broken function-level authorisation - a regular user calls an admin endpoint because the API only checks authentication, not role. Admin functions must enforce role checks server-side.
- Excessive data exposure - the API returns all fields from a database record and relies on the client to filter what the user should see. Always filter data server-side based on the caller’s permissions.
Implement authorisation checks at every endpoint, on every request. Never assume that if a user can list resources, they can also modify or delete them.
Rate limiting and throttling
Without rate limiting, APIs are vulnerable to:
- Brute force attacks - automated credential guessing against login endpoints.
- Denial of service - overwhelming the API with requests until it becomes unavailable.
- Scraping - extracting large volumes of data by iterating through endpoints.
- Cost exploitation - driving up cloud compute and egress costs.
Implement rate limiting at multiple levels:
- Per-client - limit requests per API key or user token within a time window.
- Per-endpoint - sensitive endpoints (login, password reset, payment) should have stricter limits.
- Global - protect overall API capacity against coordinated attacks.
Return appropriate HTTP status codes (429 Too Many Requests) with retry-after headers so that legitimate clients can adapt.
Input validation
Every API endpoint accepts input - query parameters, request bodies, headers, path variables. Every input is a potential attack vector.
- Validate type, length, format, and range for all parameters. An endpoint expecting a numeric ID should reject anything that isn’t a number.
- Use schema validation - define your API contract with OpenAPI/Swagger and validate incoming requests against the schema.
- Reject unexpected fields - if the API expects three fields, reject requests that include a fourth. This defends against mass assignment attacks.
- Sanitise output - even with input validation, encode output to prevent injection into downstream consumers.
Encryption
- TLS everywhere - all API traffic must be encrypted in transit. Use TLS 1.2 or higher. Disable older protocols.
- Certificate management - automate certificate renewal (Let’s Encrypt or equivalent) to avoid expiry outages.
- Encrypt sensitive data at rest - API responses that contain personal or financial data should originate from encrypted data stores.
- Mutual TLS (mTLS) - for high-security service-to-service communication, mTLS verifies both client and server certificates.
Logging and monitoring
API security is incomplete without visibility. Log every meaningful event:
- Authentication successes and failures
- Authorisation denials
- Rate limit violations
- Input validation failures
- Error responses (especially 4xx and 5xx patterns)
Centralise logs and monitor for anomalies: unusual traffic volumes, spikes in authentication failures, requests from unexpected geographies, or patterns that suggest automated enumeration.
A security operations capability - whether internal or partnered - ensures that API security events are detected and responded to in real time.
API gateways
An API gateway sits in front of your backend services and provides centralised enforcement of security policies:
- Authentication and authorisation - verify tokens before requests reach backend services.
- Rate limiting - enforce throttling policies consistently across all endpoints.
- Request transformation - strip unnecessary headers, validate schemas, and normalise inputs.
- Logging and analytics - capture traffic data for monitoring and troubleshooting.
- TLS termination - handle encryption at the gateway to simplify backend configuration.
API gateways also enable versioning, canary deployments, and traffic routing - operational benefits that complement security.
Testing your API security
Static analysis (SAST)
Analyse source code for security vulnerabilities before deployment. Look for hardcoded secrets, insecure patterns, and missing validation.
Dynamic analysis (DAST)
Test running APIs by sending crafted requests and analysing responses. DAST tools simulate attacker behaviour - injection attempts, authentication bypass, authorisation testing - against live endpoints.
Fuzzing
Send random, malformed, or boundary-case inputs to API endpoints and observe how they respond. Fuzzing uncovers unexpected behaviour, crashes, and error-handling gaps that structured testing might miss.
Penetration testing
Engage experienced security testers to manually probe your APIs. Automated tools catch common vulnerabilities; human testers find logic flaws, chained exploits, and business-specific risks that tools miss.
The OWASP API Security Top 10
The OWASP API Security Top 10 (2023 edition) provides a focused risk framework:
- Broken object-level authorisation - accessing other users’ resources
- Broken authentication - weak or missing authentication mechanisms
- Broken object property-level authorisation - exposing or modifying properties that should be restricted
- Unrestricted resource consumption - no rate limiting or resource controls
- Broken function-level authorisation - accessing admin or privileged operations
- Unrestricted access to sensitive business flows - automated abuse of business features (e.g., ticket scalping)
- Server-side request forgery - the API can be tricked into making requests to internal systems
- Security misconfiguration - default settings, verbose errors, open CORS
- Improper inventory management - forgotten, deprecated, or shadow APIs still running
- Unsafe consumption of third-party APIs - trusting data from external APIs without validation
Use this list as a checklist during design, development, and testing phases.
Getting started
API security is a continuous discipline, not a one-time project. Start with the fundamentals:
- Enforce authentication on every endpoint.
- Implement object-level authorisation checks.
- Add rate limiting to sensitive endpoints.
- Validate all input against a defined schema.
- Log and monitor API traffic.
ITHQ builds and secures APIs for South African businesses. Our web application engineering team designs APIs with security built in, supported by cybersecurity operations and identity and access management to ensure your APIs are protected end to end.
Contact us to review your API security posture or discuss a secure API development strategy.