12 API Security Best Practices to Protect Your Business
By Katrina Thompson
Sometimes the best things in life aren’t free. APIs, for example, might be the biggest technological enabler of the modern digital era but they come at a price. Since they are the hub that connects one organization’s service to another’s, they are also prime targets for hackers who want to cash in on the wealth of data behind those doors.
Research from API security firm Salt indicates that a high number of threat actors have already ‘cashed in’. There was a 400% spike in API attacks in the latter part of last year, and a full 94% of survey respondents had experienced a security issue with their production API. The list ran the gamut from vulnerabilities (41%) to credential stuffing (20%) to enumeration and scraping (one in ten).
That’s why the cost of successfully using APIs to enable growth, scalability and ease of use is strong security.
Here are twelve tips to securing your API ecosystem so you can scale safely.
- Encrypt, encrypt, encrypt. This one’s a given, and not all encryption is created equally. APIs directly access databases, and all data should be encrypted at rest. They also send data via multiple channels, warranting the need for all data to be encrypted in transit. Only the latest version of TLS (1.3) should be used.
- Authenticate always. APIs are a gold mine for hackers wanting a one-stop-shop into a number of different ecosystems. It’s like capturing a train station and being able to ride any train to any destination – as opposed to jumping on a single train headed down the tracks. Authentication measures ensure the party requesting access is a legitimate user. Methods include HTTP Basic (username and password), an API key (each user needs a unique identifier), and tokenized authentication such as OAuth2.
- Implement access controls. This goes hand-in-hand with proper authentication: Once your approved users are identified, you need to specify what kind of access they have to the API and the data behind it. This is especially important when you allow external, third-party access. Clearly define the rules (who gets access to what, when) and lean into technical checks such as firewalls, WAFs, web application gateways, rate limits, geo-fencing, and content validation.
- Validate data. Again, this dovetails into the previous precaution. APIs often come laden with hidden bugs (especially when hot off the OS press) and each organization needs to do its due diligence to ensure API data is cleansed and validated properly. Debugging tools can track errors and clean routines can stop cross-site scripting attacks and injection flaws.
- Watch it like a hawk. This means monitoring your API like it was a newborn. At any given time, your SOC should know what version each of your APIs are running, how many there are, where they are, and the usual traffic patterns for each (the better to spot anomalies, my dear). Doing all this will likely require some sort of API management or security platform, especially if you’re an enterprise.
- Implement runtime protection for APIs. Runtime monitoring and protection can help organizations buy time in the event of an ongoing incident. Take log4j, for example. Before you could determine if you were vulnerable, you first had to find it. And that takes time. Meanwhile, exploits could be busy doing damage. Runtime protection secures functions in real-time to combat any malicious activity already underfoot. It keeps the damage from spreading while you investigate as it identifies and prevents malicious API requests during their normal functioning periods.
- Perform regular risk assessments. Organizations need to always be on top of not only the status of their APIs, but the security temperature as well. Do they have any out-of-the-box vulnerabilities (OS repositories…) that leave them exposed to known hacks? Were they patched properly the last time? Are they at risk of any of the OWASP API Security Top 10? Going over this with a fine-toothed-comb – and not merely paying lip service – usually means pentesting your API environment and even subjecting it to a few Red Team exercises: Part of protecting your API space is making sure your security team passes muster when it comes to facing down an attack.
- The less you know…In other words, operate on a need-to-know, zero trust basis. This should apply to everyone always when working with APIs. They have the potential to access so much data, and so much of it is confidential. To do this, astute programming is required. A response to an API call shouldn’t include more information than the user asked for, such as when a whole field will turn up instead of a single data point (relying on the user to ‘filter’ for themselves). Threat actors can use any bit of data to their advantage and APIs that inadvertently expose unsolicited facts, business logic, database structure, or architectural back-end details are at risk.
- Use throttling, have quotas. While alluded to before, this point deserves its own soapbox. APIs are sensitive to DDoS attacks, same as everything else online, and throttling limits are a must. Limit both ways: have a cap on how many overall calls your API can handle per second, and put a quota on how many requests a single user can put in within a certain amount of time. No typical user would need to know twelve separate pieces of information instantaneously, and if they do – they can wait.
- Your team matters. This is referring to your team of tools that support your API ecosystem. It’s a tough job – APIs can’t do all the work. That’s why it’s important to make sure your surrounding network architecture (infrastructure, software, servers) is up-to-date and not letting flies in that your API is going to have to swat.
- API gateways. This is a good way to get a lot of API security benefits in one. An API gateway sits between your API client and your backend services. When an API call comes in, the gateway sorts it all out, routes the requests to the right location, and shields your API proper from any mess or vulnerabilities backstage. In addition to enabling scalability (you’ve got authentication, routing, monitoring, rate limiting, etc. all in one place), it augments security as any data passing through the gateway (traffic stats, anomalies, alerts) will be recorded and available for future use. API gateways are a good all-in-one API management tool.
- API security platforms. This can slide in alongside a management solution, or it can stand alone. Either way, the benefit of an API security platform needs to be considered. While an API management platform provides an overall lift, an API security platform takes care of one thing, and one thing only – security. And it does it very, very well. A specialized API security platform doesn’t split resources with other management functions and can devote that extra bandwidth to granular practices like scoping out flaws in business logic, identifying cases of exposed API data, classifying API calls for better analysis, blocking OWASP API Top 10 threats, and testing production APIs for security gaps.
- Hide your keys. API keys are used to implement security protocols like throttling or verifying access when a site calls an API. However, they are not as secure as authorization tokens and can be sloppily handled. API keys should not be embedded in the applications source tree or, worse, directly in the code. It happens. Instead, hide them outside of the direct line of fire, engage a key manager, and rotate them every so often (the more, the better).
We all know that Gartner predicted that by 2022, APIs would be the “most-frequent attack vector.” And as APIs continue to proliferate, attacks will only continue to increase in size, sophistication, and frequency. However, there’s one thing to keep in mind.
Bad actors will always try the door before breaching the window, so organizations shouldn’t discount common sense. The more teams double down on API security best practices, the more likely they are to seem ‘too tough to breach’. Attacks on APIs may not stop, but by implementing the proper security precautions, companies can make sure they’re not the low-hanging fruit.
An ardent believer in personal data privacy and the technology behind it, Katrina Thompson is a freelance writer leaning into encryption, data privacy legislation and the intersection of information technology and human rights.
She has written for Bora, Venafi, Tripwire and many other sites.