So, when protecting an API, what do you need to keep in mind?
Start by finding out if there are any existing requirements regarding security within your organization. This step is sometimes overlooked and leads to loads of unnecessary work and less secure API: s. These requirements may explain what security mechanisms that you need to enable in your API Management System and how to configure them. Keep in mind that depending of the scenario, the API might need different levels of protection.
If you are unable to find any requirements, (which according to some studies is quite common 1), you might need to decide how to protect them yourself, here are some general rules of thumbs for that situation.
- Don’t invent your security mechanisms; use standardized ones. The standardized ones have been proved to be secure and competence about them are easier to find.
- Have security in mind even when you design your API: s. Be careful to not expose sensitive information or private keys to such, like social security numbers or credit card numbers.
- Don’t place confidential information in the query string. The will typically be logged in files or even be visible in analytics software.
The following areas would need to be addressed by the API Security mechanisms:
Encryption: Encryption makes it impossible or at least very expensive to eavesdrop on the communication between the App and API. It’s also the mechanism that ensures that the App communicates with the correct API and not a phony one. In addition it is the mechanism that ensures that credentials and tokens will stay private and not get in the wrong hands. You need decide what kind of encryption mechanism to use for different kinds of scenarios. It is good practice to encrypt all calls to the published API: s, even in “internal” scenarios where all parties are on prem. Why? It is costly in terms of time and money to implement it afterwards.
Authentication: Decide in what way the App / End user identifies themselves to the API, and in what identity system their credentials are stored.
Authorization: Decide in what way an API call from the App / End user is granted or refused by an API to ensure that the APIs are used only by the intended users.
Validation: Decide how to make sure that the API:s are used in the way they are intended. Depending on the API Management platform, some validations take place implicitly. Different kinds of validations may be applicable in different kinds of scenarios.
- Is there a route in the API specification for the API call being made? Does method, URL, and parameters match a known combination. Only permit the calls that matches.
- Validate that information sent from the App is not malicious. Validate that the content type is accepted by the route, and that the content in the body is of the specified content-type. This information is typically in the API specification. If there is a schema in the API specification for the route, the best solution would be to validate the body against that schema. If not, several API Management systems have built in policies for validating different kinds of content. Some even have a build in antivirus for binary content.
- Validation of certain headers aims to make sure that session headers or cookies exists and are valid. Some API Management Systems also have support for CORS headers.
- Some API management systems have policies that filters out headers from API calls. This is a really sound feature that will protect API: s in the backend.
- Validate that App IP address is in / is not in within range of IP addresses. This may be useful in some scenarios where a firewall is missing or is hard to configure.
- Some API management systems offers protection from denial of service attacks. This may be useful in some scenarios where other layers doesn’t provide this protection.
Monitoring Detect: Log and deny malicious requests access to the API in addition to alerting responsible.
Never forget that API security is an ever-evolving topic, and constantly needs to be reviewed!
Martin Svensson, Integration Architect at Enfo