Application program interfaces (APIs) form bridges between applications, enabling programs to talk to each other across differing code bases and hardwares. But in the wrong hands, APIs can inflict potentially massive damage.
Enterprise applications form bigger and bigger attack surfaces, but often it’s the APIs where the real vulnerabilities lie. While many attacks may be detected and thwarted through standard firewalls and SIEM tools, attacks through APIs move more stealthily, as they often leverage the access privileges the API already allows. These vulnerabilities extend well beyond the enterprise realm, and are even potentially affecting your personal vehicle. So ubiquitous are insecure APIs, that they’re even being used to hack Teslas.
Here is how to adopt a more rigorous security posture with APIs by implementing the following strategies.
Table of Contents
1. Build For Future Users, Not Present Ones
When APIs are in their infancy, they are often designed to satisfy the needs of a small team of developers working together. These developers know each other, maybe even share an office space, and may feel little need to implement authentication protocols to establish that everyone is who they claim to be. Why should they? Before long, a particularly useful API finds its way out of the team, and it crawls its way to a broader network of users than was originally intended. The appropriate security measures should be in place before the genie gets out of the bottle, rather than long after.
2. Limit Users
Speaking of future users, plan for many but control for fewer, if possible. Authorize access on a strictly need-to-know basis. More users means a greater attack surface, particularly if privileges aren’t clearly and thoroughly defined.
3. Limit Data
The Equifax data breach represents the sum of all fears, as the company housed private financial information for nearly 150 million Americans. Fortunately, not every company’s business model necessitates the collection of social security numbers, driver’s licenses, addresses, and so on. Narrowly tailor data collection so only the most necessary data is required. Uncollected data is safeguarded.
4. Encrypt Data
Ensure that communications pathways are using the appropriate encryption protocols such as SSL or TLS. Similarly, data at rest should be encrypted. This may seem like obvious advice, but all too often a data breach occurs because accounts and passwords were stored in plain text. Simply having encryption isn’t enough, it also has to be used correctly. Some protocols such as TLS allow for encryption verification to be disabled on the server or the client side, resulting in a potential exposure for internet traffic to be intercepted. Ensure that APIs conform to the latest security best practices to ensure that communications are safe and secure.
Read more about API security: 7 Trends in Network Management APIs
5. Enact Pagination Limits
Without proper API pagination, server queries can return one result or one hundred billion. The latter scenario would quickly devour system resources and bring applications to a halt. Even worse, it doesn’t require a malicious actor to cause harm—an innocent user might frame a query too loosely, and receive a staggering response. Fortunately, pagination is easy to implement. The easiest form of which is offset pagination, which provides users with a predefined window of records that they can retrieve. Other forms of pagination include keyset and seek, which have their own benefits and disadvantages.
6. Use Prepared Statements in SQL Queries
SQL code injections are incredibly prevalent attacks, giving attackers the ability to pose as other users, damage databases, or steal data. As is implied by the name, the attacker sneaks SQL code into a database query, often through the abuse of escape characters that a properly configured server should have filtered out. Prepared statements inhibit an attacker’s ability to inject SQL code by blocking them with placeholders that are only able to store specific values, and not SQL fragments. Another method of preventing SQL injections is to ensure data inputs match what is expected. For instance, phone numbers should register as integers and not contain strings. Names should contain letters but not numbers.
7. Strengthen End User and Application Authentication
For users accessing applications, implement routine password reset policies in accordance with the latest security best practices. For the applications themselves that interact with APIs, use unique credentialing for each version of the application, making it easier to root out out of date versions.
8. Impose Rate Limits
Brute force attacks happen when an attacker sends high volumes of login credentials to a server in an effort to make a successful match through sheer chance. A basic rate limit can thwart these attacks, by preventing more than one query from occurring within a reasonable time frame. Would a human being be capable of entering their password four hundred times in a minute? Likely not. So why would an API accept such an unreasonably high number?
Managing Risk
Security is the art of managing risk, not eliminating it. No fortress is impregnable, but attackers tend to move in the path of least resistance and target victims with poor security standards. Ratchet down your API security, and be the target attackers know to avoid.
Read next: Application Security Code Reviews: Best Practices
