Katrina Thompson 

Your web application has a weak spot, and every cybercriminal knows about it: APIs. These interconnected hubs of data requests are perfect entry points for threat actors looking to infiltrate online programs that are otherwise protected. 

Way back in 2020, a SlashData survey reported that nearly 90% of developers used APIs. Rapid’s 2022 State of APIs report noted that this year, roughly 70% of developers are planning on increasing that use. APIs have all but taken over software development, and are heavily invested in making web applications simple, compatible, and agile.

However, along with that use comes a greater attack surface and exponentially increased risk. According to the Q1 2023 State of API Security Report from Salt, the end of last year saw a 400% increase in the number of API-targeted attacks over just a few months prior.

Here are some of the most common API-based security challenges to beware of when guarding your web applications.

1. API key generation | Typical API security tools can spot anomalous behavior and block API key access. However, threat actors leverage large swaths of API keys, obtained from users, to overwhelm and evade these protective measures. If they are on the lookout for one bad key, they aren’t going to find it. This is similar to the way black hats employe swaths of IPs to get around similar DDoS protections. How to protect against this? Anticipate bots by requiring MFA or biometrics and require the API keys to be generated by the human that signs up for the service. 
2. DDoS attack | APIs’ very convenience cuts against them sometimes. The ability for customers to access APIs programmatically is a huge step towards usability – but unfortunately confuses security systems like DDoS protection solutions. Trained to recognize and reject the bad requests made during a DDoS attacks, the nature of API calls can make all traffic look like bot-based traffic. The only way around this is to reject all API traffic without a legitimate API key, instead. 
3. API logging | This is a challenge because once API logging is in place, it can seem sufficient. All too often, it is not. The purpose of logging API traffic is to be able to go back, trace back, and analyze API requests all the way back to the users, linking them with bad behavior when necessary. Sometimes logs will just track API requests. This is not enough, and the logs that are stored need to be held safe for at least a year. When so much nefarious activity takes a long-game approach, logs that are shallow or short-term fail to provide the insight needed to catch bad guys in the act. 
4. Improper authorization | While a user may be properly authenticated, there is often a divide between how many of those are also correctly authorized. There is a difference, and that difference makes all the difference. Authorization has to be baked into the web application’s very logic – for this reason, it can be a blind spot many developers miss, leaving the web application only partially protected. Developers need to take the extra step towards zero trust, ensuring that everyone that is authenticated is also authorized to access the resources on the other side of the API response. 
5. API key exposure | Why only lock the door when you could use a deadbolt? The same thinking applies when preventing sensitive API key exposure. There are three ways in which these keys can be leaked:
   1. No expiration date. API keys with an indefinite shelf-life can be dangerous if obtained by a criminal hacker down the road, and sits around as an exposed liability for that much longer. 
   2. No questions asked. Once you have an API key, no further identification is needed. But what if that person stole the API key? One critical weakness is that APIs can’t leverage 2FA or one-time use tokens to verify identity one layer down. 
   3. Exposed access. When someone gains access to an API, they also gain access to the web application’s credentials. If a careless, tired, or inexperienced developer makes a mistake, they could very well copy-and-paste the API key (and CURL command) into a public repository. Keep in mind the Verizon 2023 DBIR notes that 74% of all data breaches stem from human error. 

To steer away from accidentally exposing sensitive API-only data, try generating tokens that will grant the user resource access for a short time only. This is in contrast to the currently held practice of storing refresh tokens in the environment. This method re-authenticates a user without causing them to log in again, resetting the timeline for which they are verified. However, should the key fall into the wrong hands at any time, the practice presents undue risk. A short-lived token is a safer, more secure alternative.

APIs are becoming synonymous with business growth, software creation and web application development. While they serve the part of force-multiplier and enabler, they also can present web apps with some of their greatest risks. Staying on the right side of the line means knowing the vectors, understanding the threats, and not underestimating APIs when it comes to web application security. 

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.