Introduction

APIs allow applications to exchange information, connect cloud services and support digital business operations. They are now fundamental to web applications, mobile platforms, microservices and third-party integrations. However, every API endpoint can also introduce a potential entry point for attackers.

A poorly protected API may expose sensitive information, allow unauthorised actions or consume resources through excessive requests. These risks can affect customer data, application availability and business operations.

The OWASP API Security Top 10 identifies major API vulnerabilities, including broken authentication, broken object-level authorisation and unrestricted resource consumption. Addressing these risks requires security controls throughout the API development lifecycle.

1. Strengthen Authentication and Authorisation

Authentication verifies who or what is making an API request. Authorisation determines what that identity is permitted to access.

Use established authentication mechanisms, such as OAuth 2.0 and appropriately secured access tokens, rather than designing custom authentication systems without specialist review. Require HTTPS to protect credentials and tokens in transit, and apply suitable token expiry and revocation controls.

Authorisation must be checked at every relevant endpoint. A user who can access their own account should not automatically be able to retrieve another user’s information by changing an object ID in a request.

OWASP identifies broken object-level authorisation as a leading API security risk. Apply access checks to individual records, functions and sensitive object properties.

2. Apply Rate Limits and Resource Controls

An API that accepts unlimited requests can become vulnerable to denial-of-service activity, automated abuse and unexpected infrastructure costs.

Implement rate limits based on factors such as user identity, API key, IP address and endpoint sensitivity. Set request-size limits and apply appropriate timeouts. Return HTTP 429 (Too Many Requests) when a client exceeds the permitted request rate.

Sensitive business operations, such as account creation, payment attempts and password recovery, may also need additional abuse-prevention controls.

3. Validate Requests Against Defined Schemas

Never assume incoming API data is trustworthy. Validate request parameters and payloads against an explicit contract or schema.

Check data types, required fields, permitted values, string lengths and request formats. Reject unexpected properties where appropriate, and restrict supported content types and HTTP methods.

Schema validation helps reduce malformed input, injection opportunities and unintended data modification. It should complement, not replace, authorisation checks and secure application logic.

4. Protect API Keys and Secrets

API keys, passwords, signing keys and access tokens must not be embedded in publicly accessible source code or exposed through client-side applications.

Store sensitive credentials in a dedicated secrets-management system or secure configuration environment. Restrict access according to workload requirements, rotate credentials when appropriate and revoke exposed or compromised keys promptly.

Avoid placing credentials in URL query parameters, where they may appear in logs and other records. Use secure headers or request bodies as appropriate to the API design.

5. Monitor API Activity and Maintain an Inventory

API security requires visibility into how endpoints are being used. Monitor authentication failures, unusual request patterns, access-denied events, traffic spikes and unexpected changes in resource consumption.

Maintain an inventory of production, development and legacy APIs. Document endpoint owners, versions, authentication requirements and data sensitivity. Retire obsolete endpoints and restrict access to management interfaces.

Logs should support investigation without unnecessarily recording passwords, tokens or other sensitive information.

6. Test APIs Throughout Development

Include security testing in development and release processes rather than waiting for a production incident.

A practical testing programme should include:

• Authentication and authorisation tests using different user roles.
• Attempts to access another user’s records.
• Input validation and unexpected payload tests.
• Rate-limit and request-size tests.
• Checks for exposed secrets and insecure configuration.
• Dependency and third-party API security reviews.

Use automated testing alongside manual security assessments. Reassess APIs when endpoints, permissions, integrations or business workflows change.

Conclusion

API security depends on several controls working together. Strong authentication, endpoint-level authorisation, rate limiting, schema validation, protected secrets and continuous monitoring reduce the risks associated with connected applications.

Organisations should use the OWASP API Security Top 10 as a starting point, maintain an accurate API inventory and integrate security testing into development. Protecting APIs is an ongoing responsibility that must evolve alongside application architecture and business requirements.

For broader context, read TechRay News’ coverage of cybersecurity and business needs from a CISO’s perspective.