APIs are amazing. They open a new world of productivity, enabling the app- and data-driven world we live in today. APIs allow our app frontends to make requests to server backends, and servers to control other servers.
Hold on, take a step back here: APIs enable what?
Yes, they open your servers and let other apps, programs, and people control them. Effectively, APIs provide remote access to your servers and your organization’s data, often via the open Internet. That can be a scary thought.
Common Attacks Against API Endpoints
When users interact with an API, their HTTP requests find their way to the API endpoints, which are the servers that process the API requests. As you might expect, primary targets for attackers. The most common attacks include:
Broken authorization
This is by far the most common form of API attack, consistently earning top spots in the OWASP API Security Top 10 list. All authorization issues, combined, account for well over 50% of API endpoint attacks. They include various forms of misconfigured or bypassed authorization, which allow attackers to gain access to unintended areas or perform unintended functions (such as changing or deleting information).
Broken authentication
Attackers gain access by stealing valid session tokens or through account takeover (credential stuffing or brute force).
DoS/DDoS attacks
Attackers flood API endpoints with traffic or targeted requests that generate excessive processing.
Request forgery and injection
Attackers create targeted attacks using modified URL paths or additional code, causing unintended code execution on API endpoints or backend servers.
Misconfiguration
Incorrect configuration on API endpoints or network appliances exposes the API endpoint to unauthorized access.
Notice the theme here: Most of these attacks stem from API endpoint configuration. You likely have mechanisms in place to ensure only authenticated users have access authorized functions. Have you thoroughly tested these mechanisms? Have you considered unexpected input values or parameters? How do you even run these tests?
Common Network Security Tools
You may be asking, what about all those security tools we have in place?
Network firewalls
These protect against unauthorized access to application/server ports and scans. Good at blocking layer 3/4 DDoS (SYN floods, ICMP attacks). They have no idea what is happening inside an HTTP/HTTPS connection, where API calls take place. It’s all port 80 and port 443 traffic. And it’s all open to the Internet.
Logging and monitoring
Useful for detecting unusual activities. But what about attacks that look like normal API requests? How can the logging and monitoring tools differentiate a normal API request from an attack?
Web application firewall (WAF)
These protect against layer-7 attacks (e.g., cross-site scripting/forgery, SQL server injection) and layer-7 DDoS (HTTP flood). But without detailed knowledge of how an API works (structure, format/data types, paths, responses), there is no way to differentiate a normal API request from an attack. It’s just another HTTP request and response payload.
Best Practices for API Endpoint Protection
API definition/API documentation
Misconfigurations and security holes often result from poor design or incremental patching over time. If authorization issues are the #1 form of API attacks, what is your best defense? Ensure your APIs are well organized and thoroughly understood. Document your APIs using a standard format like OpenAPI. Regularly review your API definitions against your actual code to ensure accuracy and consistency.
API request validation
Always validate API requests before forwarding them to your API endpoints. This practice ensures API requests adhere to defined constraints, prevent malicious inputs, and block attacks attempting to overload the API endpoints. By utilizing a WAF or API gateway capable of importing and validating API requests based on your OpenAPI definitions, you achieve the dual objectives of maintaining robust API definitions and enforcing security.
Strong authentication
Utilize a robust authentication framework (e.g., OAuth). Keep session expiration and timeout periods short and consider multi-factor authentication (MFA).
TLS encryption
Always use HTTPS with a public (CA) TLS/SSL certificate. End-to-end encryption, from browser to API endpoint server. Always. Network encryption protects you against man-in-the-middle attacks, such as session hijack and data manipulation. Use the highest TLS version with the best cipher suites that are compatible with your browser/client base.
Limit access
Whenever feasible, restrict access to your API endpoints. Reduce your attack surface. Why expose your API endpoints to the entire world when only a handful of users need access?
- Client source IP allow-list/deny-list
- Client TLS/SSL certificate/mutual TLS authentication
- Geo-IP allow-list/deny-list
DoS/DDoS protection
Deploy a WAF with layer-7 DoS and DDoS protection, including API request rate limiting/throttling and source IP reputation rules. Ensure the WAF can scale up for large DDoS attacks. More details about this in a future blog.
Updated WAF rules/signatures
Underneath the hood, API endpoints are web servers. New security exploits appear daily, particularly those targeting web servers. A WAF with up-to-date rules and signatures not only safeguard against past vulnerabilities but also protect against future threats. A robust, well-managed WAF helps shield your API endpoints from potential risks.
APIs are great for business, but they also expose your organization and its data to the world. Protect yourself accordingly.
Interested in learning how Fortra Managed WAF can help you protect your APIs? Check it out or schedule a demo.
Additional Resources:
Trends in Modern Application Protection
Eliminating the Complexity of Application Security | Webinar
