API security best practices for IT leaders

APIs let applications exchange data and request actions. They support many mobile apps, service integrations and partner connections. An API can expose sensitive data or business actions even when its interface has no visible webpage.

An API security review should establish who can call each endpoint, which data they can access and what prevents abuse. Those questions apply to internal services as well as public interfaces.

Why API security deserves board-level attention

Most organisations have invested heavily in perimeter security, endpoint detection and identity management. API security spans those areas and application security, which can leave ownership unclear.

An inventory can reveal internal, external, partner-facing and retired interfaces with different owners and controls. Verify those differences in your own estate rather than assuming a gateway covers every route.

The business risk is real. A single misconfigured API can expose customer data, enable account takeover or allow competitors to scrape proprietary information at scale.

The OWASP API security top 10

The OWASP API Security Top 10 is a useful starting point for understanding API-specific risks. The 2023 edition highlights these critical vulnerabilities:

Broken object level authorisation (BOLA)

OWASP lists this as API1 in its 2023 edition; that position is not a measurement of its frequency in your business. It occurs when an API endpoint accepts an object identifier from the user but fails to verify that the user has permission to access that specific object. An attacker simply changes the ID in a request to access another user's data.

What to do: Implement authorisation checks on every data access function. Never rely on client-side filtering. Random, non-sequential identifiers can make enumeration harder, but they do not replace an authorisation check.

Broken authentication

APIs that implement authentication incorrectly can be exploited through weak token generation, missing validation or credentials sent in URLs.

What to do: Distinguish OAuth 2.0 authorisation from OpenID Connect authentication. Validate tokens for the intended issuer, audience, expiry and permitted use. Select a credential mechanism appropriate to the client and risk; a static key alone does not establish an end user's identity or permission to a record.

Unrestricted resource consumption

APIs without rate limiting or resource quotas are vulnerable to denial-of-service attacks and cost-based attacks against cloud-hosted services.

What to do: Implement rate limiting per user, per endpoint and per IP. Set maximum payload sizes. Monitor for unusual consumption patterns.

Building your API security strategy

Rather than treating API security as a purely technical exercise, approach it as a governance and architecture challenge. Here is a practical framework.

1. Discover and inventory your APIs

Include APIs that do not appear in the central catalogue. Shadow APIs are those created without central oversight and may lack the agreed controls.

Start with automated discovery using API gateway logs, network traffic analysis and code repository scanning. Build a living inventory that captures each API's purpose, owner, authentication method, data sensitivity and lifecycle status.

This ties directly into broader IT governance practices. Your API inventory should be part of your data governance framework.

2. Standardise authentication and authorisation

Establish organisation-wide standards for API authentication. Choose mechanisms against the client and threat model. OAuth 2.0 can provide delegated access; OpenID Connect supplies an identity layer where user authentication is required. Service identities may use short-lived credentials or mutual TLS. Define token lifetime, credential storage, rotation and revocation, then enforce least privilege at the resource.

If you have already adopted an identity-first security approach, extend it explicitly to cover non-human identities including service accounts, API clients and automated workflows.

3. Implement API gateways as policy enforcement points

An API gateway can apply shared controls to traffic that passes through it. Use it to enforce:

• Authentication. Validate tokens before requests reach backend services
• Rate limiting. Protect against abuse and denial-of-service
• Request validation. Check payload schemas, reject malformed requests
• Logging. Record the security-relevant request context without storing credentials or unnecessary personal data

The application still needs object-, property- and function-level authorisation. Restrict direct access that could bypass the gateway, protect the gateway-to-service connection and validate caller context at the service. Shared controls reduce repetition; they do not remove the service owner's responsibility.

4. Shift security left

API security testing should happen during development, not after deployment. Integrate these practices into your DevSecOps pipeline:

• API specification review. Mandate OpenAPI or AsyncAPI specs and review them for security issues before any code is written
• Automated security scanning. Run authorised tests against scoped non-production API endpoints with synthetic data and safe rate limits
• Contract testing. Verify that APIs behave according to their specification and reject unexpected inputs
• Threat modelling. Include APIs in your threat modelling exercises, focusing on data flows and trust boundaries

5. Monitor and respond

Runtime API security monitoring is essential because static analysis cannot catch every vulnerability. Focus on:

• Anomaly detection. Baseline normal API usage patterns and alert on deviations
• Sensitive data exposure. Scan API responses for unintended data leakage such as internal IDs, stack traces or excessive personal data
• Authentication failures. Monitor for brute force attempts and credential stuffing
• Geographic anomalies. Flag API calls from unexpected locations

Feed this telemetry into your existing security operations workflow. If you have invested in observability, extend those practices to cover API-specific metrics.

Common API security mistakes

Treating a secret key as sufficient authorisation. Credential-bearing API keys are secrets. Keep them out of source code, URLs, logs and browser bundles; scope and rotate them, and revoke exposed keys. Some providers also issue deliberately public identifiers, which are different. A secret key authenticates a client only to the extent designed by the service; it does not automatically grant permission to every user, object or action.

Ignoring internal APIs. The assumption that internal APIs are safe because they sit behind a firewall is dangerous. Lateral movement after initial compromise is a standard attacker technique. Apply the same security controls to internal APIs as external ones. This is core to any zero trust approach.

Over-exposing data. APIs that return entire database records when the client only needs two fields create unnecessary risk. Design APIs to return the minimum data required. Use field-level filtering at the API layer, not the client layer.

No versioning or deprecation strategy. Old API versions with known vulnerabilities persist because nobody has a plan to retire them. Establish clear versioning policies and sunset timelines.

Test the business rule as well as the token

Consider a hypothetical customer portal with an invoice endpoint. Alice signs in legitimately and requests her own invoice. That test passes. Next, an authorised tester in a non-production environment changes the identifier to Bob's invoice. The service must refuse the request even though Alice's token is valid. Repeat the test for restricted fields and administrative actions.

Also test the cost of a permitted operation. A report endpoint may accept valid input yet launch an expensive query for every request. Bound its date range, concurrency and result size, then confirm the limit works for each caller. A global request-rate limit alone may not capture that cost.

Keep the request, expected result and observed result in the acceptance record. Use synthetic accounts and data; never explore another real customer's records to demonstrate the issue.

A practical starting point

If you are starting from scratch, prioritise these five actions:

1. Audit your API inventory - Find every API, document its owner and classify its data sensitivity
2. Provide shared enforcement - Use appropriate controls, which may include a gateway, alongside service-level authorisation
3. Review credentials and authorisation - Use suitable client or user authentication and resource-level permission checks
4. Add API testing to CI/CD - Automate security scanning for every API change
5. Monitor runtime behaviour - Implement anomaly detection for API traffic patterns

Estimate the work for the APIs in scope, including legacy consumers, tests and operational support. Start with a high-impact service whose owner can act on the findings.

The strategic view

API security is not a one-off project. As your organisation adopts more microservices, integrates more SaaS platforms and builds more partner ecosystems, the number of APIs to govern grows.

Provide shared controls that development teams can use, and assign responsibility for maintaining them.

Start with discovery, standardise your controls and build security into the development lifecycle. The technical solutions exist. Define ownership and review how consistently teams apply them.

---

If you need help assessing your API security posture or building the governance framework to support it, my IT compliance services cover security architecture review and control design, and my technical consulting service can support API strategy and architecture decisions. Get in touch to discuss your security challenges.