Securing HTTP-based APIs

An API endpoint is an URL that is used by a client to connect to an API.  API endpoints that are exposed to customers should be managed effectively. Unless access is strictly limited to trusted networks (or devices outside an attacker’s control), attackers will likely have some level of access (potentially through methods like decompiling apps to extract API endpoints and keys).

Remove unused endpoints

When an API is updated sometimes endpoints are left exposed, especially if an API is being (or has been) decommissioned. In this case it would likely mean that all monitoring and security features would be inactive, especially if it is no longer in use. It could also mean an API endpoint that's potentially vulnerable is exposed and accessible. When an API endpoint is being deprecated the IT team needs to ensure that the endpoints are no longer accessible and access is blocked. The asset register mentioned in section 1 will help with this.  

Restrict access to privileged endpoints

Endpoints that are considered sensitive (such as the one used for administration of an API) should also have restricted network access and should not be publicly accessible.  This makes it harder for an attacker or malicious user to access the sensitive API and attempt to exploit it.  You should actively scan your environment to ensure you know what is being made publicly available. This will allow you to proactively find any legacy, development or administration APIs that are overly exposed.

Block known malicious IP addresses 

Block known malicious IP addresses as well as connections from categories of IP address that should not connect to your API. Blocking IP addresses in this way is normally a function available in a number of web application firewalls (WAFs). Where possible, you should try to use managed rulesets for blocking IP addresses as this will significantly reduce your administration overhead. You will need to tune your rulesets so you may need to monitor your rules before you enforce them just in case you end up blocking legitimate traffic by accident.

API exposure for a closed community

If you are hosting a private API or one that is used in a closed community (for example a CNI sector or group of government departments) then consider limiting exposure of your API further. This could come in the form of an mTLS, an IP address allow list or using a VPN. Which method you're going to use to reduce exposure will depend on the scale, threat and requirements of your closed community. 

API responses

If APIs return excessive or unnecessary data, they risk leaking sensitive information such as internal identifiers, user personal individual identifiers (PIIs), or debug details. Such exposure can aid attackers in gathering intelligence for targeted exploits or cause inadvertent breaches of user privacy.

When deploying API at scale use an API gateway as this will provide a consistent approach to security. If you’re hosting your API in the public cloud then you should consider the use of cloud-native infrastructure rather than lifting and shifting an on-prem solution into the cloud. 

API gateways act as intermediaries between clients and backend services, providing a centralised entry point for managing and securing API traffic. The centralised nature of API gateways simplifies implementation of security features when building API at scale. API gateways can provide a way to provide a consistent implementation of security features as these are provided in the gateway, rather than the backend application code.

Some security features you can find in an API Gateway are:

• schema validation (as described in section 4)
• authentication and authorisation of a client; API gateways often support frameworks like OpenID Connect and OAuth 2.0
• provision of a central point for monitoring and logging of an API endpoint
• integration into tools like WAF and IDS that can be used as defence in depth as well as limit exposure of your API