The Ultimate Guide to Web Application and API Protection (WAAP)
Protecting and Securing Web Applications and APIs
Web Application and API Protection service key capabilities
Comprehensive Web Application and API Protection (WAAP) services, sometimes referred to as ‘Cloud Web Application and API Protection’ services, protect your web apps and APIs from a wide variety of attacks. A WAAP service should provide protective capabilities that leverage effective web request inspection prior to reaching the app or API endpoint. The key capabilities of a comprehensive WAAP service include:
- Next-Generation Web Application Firewall (Next-Gen WAF): Monitors and protects web applications from a wide variety of attacks at the application layer, wherever they are deployed.
- Runtime Application Self-Protection (RASP): Built directly into the application runtime environment, provides real-time attack protection for web apps and APIs.
- Malicious Bot Protection: Identifies and blocks attacks from malicious bots while allowing good bot traffic to access the application.
- Distributed Denial-of-Service (DDoS) Protection: Protects against denial-of-service attacks against apps, APIs and microservices both at the network and application layers. DDoS attacks aim to make apps and APIs unavailable to legitimate users by overwhelming the web layer resource with high request volumes or abusing specific functions and features of the application.
- Advanced Rate Limiting: Protects against abusive behavior at the application layer that negatively impacts website and APIs.
- Protection for APIs and Microservices: Embeds security within the application, microservice, and function levels to create a data and context-aware microperimeter around each individual service.
- Account takeover protection: Protects against attackers using compromised credentials from password lists and data dumps to gain unauthorized access to customer accounts through either an app’s customer-facing authentication flow or via authentication APIs.
A comprehensive Web Application and API Protection (WAAP) service includes each of these pieces and integrates seamlessly with your current SIEM, development and DevOps toolchains, while providing the protection and visibility required to stop attacks in real-time.
Web application and API protection best practices
While web application and API protection services can provide comprehensive protection from top attacks, they still need to be developed and implemented properly to stay secure. Below are three best practices to secure your web applications and APIs:
API gateway management
An API gateway is a single entrypoint for APIs and microservices. It sits between the microservices and their clients and tailors the APIs to each client’s needs.
Securing microservices via authorization and authentication, request throttling, IP whitelisting, rate limiting, load balancing, and logging are all primary uses of an API Gateway. An API Gateway also provides monitoring that tracks API usage.
When combined with a Next-Generation Web Application Firewall and/or Runtime Application Self-Protection solution, API Gateways provide a true defense-in-depth security for protection against web attacks including OWASP Top 10, partner API misuse, disallowed traffic sources, and more.
Authentication and authorization
Authentication confirms a user’s identification. Authorization validates that the user is granted access to the resource they are requesting.
With the rise of APIs and microservices, authentication and authorization have shifted from a point-in-time event, like authentication via a password for one web application, to continuous authorization across all activity.
A properly implemented continuous authorization model should integrate security signals directly into authorization and authentication decisions. This enables fast decision-making in the event of a compromised account by including security signals in every step of a transaction and across all activity, not just at the perimeter.
Proper authentication and authorization protects APIs and web applications from a variety of attacks, including broken object level authorization, broken function level authorization, broken authentication, and sensitive data exposure, while providing a frictionless experience for the end user.
Advanced rate limiting
Advanced rate limiting leverages thresholding and throttling to protect against abusive behavior at the application layer that negatively impacts website and API performance. Identifying, limiting, or blocking requests that could result in abusive actions ensures resources are available for legitimate customers.
For example, when too many requests are sent to an e-commerce app’s “view orders” path in an attempt to enumerate order tokens, rate limiting can stop those high-volume requests originating from known bad IP addresses.
Protecting against brute force and account takeover attacks, application and API Denial of Service (DoS), malicious high volume scripts, website content scraping, API abuse, and unintentional API overuse are all scenarios that advanced rate limiting can prevent.
Types of data attackers target from Web Applications and APIs
APIs and web applications use, store, and transmit a wide variety of data that holds significant value to attackers, including customer identification and payment details, proprietary business data, or other sensitive data.
In 2020, e-commerce fraud will cause $12 billion in losses in the US alone. The average cost per breach has increased 131% over the past 13 years, from $3.54 million in 2016 to $8.19 million today3.
The most common types of data attackers try to attain after breaching web apps and APIs include:
- Sensitive customer data
- Unpublished media (think: streaming video content not yet public)
- Payment information
- Personally Identifiable Information (PII)
- Personal Health Information (PHI)
- Customer account access
- Credit card / gift card validation and fraud
- Content scraping
Attackers use this data for a variety of reasons, including identity fraud, make fraudulent purchases, launch phishing attacks, or sell on underground markets to name a few.
Stolen data can cause significant damage to a company’s reputation and bottom line. It is critical to use a modern WAAP solution as part of an overall defense-in-depth security plan to protect your web applications and APIs and prevent a breach.
Top attacks against Web Applications and APIs
Any organization is a target: attackers know that web apps and APIs hold the keys to the kingdom. Once they’ve breached an app or publicly accessible API, they can act on their objectives. To better help developers understand the threats and vulnerabilities, the OWASP Top 10 list was developed for developers and security practitioners. And while the OWASP Top 10 API list is newer (2019), it’s not that different from the original Top 10 list, which hasn’t changed much since 2017. Net-net, these attack methods continue to be the most prevalent.
Real time attack and event data are required for application security success. Next-gen WAF and RASP technologies, when properly integrated with a DevOps toolchain, can provide visibility at the application layer and provide production-environment feedback necessary to make informed actionable security decisions.
OWASP Top 10 Web Application and API Security Risks:
This list includes both top 10 lists. Some risks are shared between the web application top 10 and API security top 10 and are only listed once.
Injection attacks: an attacker sends untrusted data to a program, which is then processed and executed. This includes a variety of attacks such as SQL injection (SQLi) and Cross-Site Scripting (XSS)
Broken authentication: incorrect implementation of authentication functions allow attackers to access sensitive information or user credentials.
Sensitive data exposure: improper protection of sensitive data, including Personally Identifiable Information (PII), Personal Health Information (PHI), and financial information, whether at rest or in motion.
Lack of resources & rate limiting: without rate limiting in place, attackers may request a large or unlimited number of resources from an API, leading to bot and Denial of Service (DoS) attacks.
Mass assignment: mass assignment functionality in API frameworks allow developers to easily send sets of data to endpoints. If endpoints are not properly protected, they can be abused by attackers, allowing them to access or modify sensitive data.
Cross-Site Scripting (XSS): a type of injection attack, data is maliciously injected into trusted content like a web application. That data is then executed by the end user, typically via a browser.
Using components with known vulnerabilities: many web applications are built as a collection of third party libraries, APIs, microservices, and open source code. If any of these components have a known, unpatched vulnerability, it can lead to data loss, privilege escalation, and more.
Insufficient logging & monitoring: proper monitoring, visibility, and logging increases the likelihood of detecting an attack, reducing an attacker’s ability to persist in a system, access and modify sensitive data, escalate privileges, and move to additional systems.
Broken object level authorization: Attackers exploit API endpoints by manipulating the ID of an object sent within the client request. End result: threat actors can request information from an API endpoint that they are not supposed to have access to. This attack normally leads to unauthorized information disclosure, modification or destruction of data.
Broken function level authorization: Because APIs are often unintentionally publicly exposed, anonymous, non-privileged users can direct requests at them, resulting in attackers accessing unauthorized functionality.
Improper assets management: Old API versions are often unpatched, so they’re enticing to attackers that want to compromise systems with no security or access controls in place. Attackers can access sensitive data or even take over an endpoint via an old, unpatched API version.
XML external entities (XXE): Attackers exploit vulnerable, often older or unmaintained XML processors with the goal of uploading XML that includes malicious code in an XML document, seeking to leverage vulnerable code, dependencies or integrations in this attack type.
Broken access control: Typically results when an application codebase has gradually grown in size over time. Instead of deliberately designing schemes regulating access from the beginning, developers have added them over time, resulting in a patchwork system that attackers can exploit to gain access or even commandeer a system.
Security misconfigurations: The most commonly seen OWASP threat that involves exploiting unpatched flaws or accessing default accounts, unused pages, unprotected files and directories, etc. to gain unauthorized access or knowledge of the system where a web app or API operates.
Insecure deserialization: Somewhat difficult to execute, but can lead to remote code execution or other attacks, including injection attacks and privilege escalation attacks.
Additional attacks beyond the OWASP Top 10:
Bot attacks: unleashes massive floods of web requests against web pages made accessible via a web application or API. Examples include form submission abuse, webpage content scraping, bot imposters, and API abuse.
Distributed Denial of Service (DDoS): targets microservices and APIs and are meant to disable specific high system cost APIs such as database queries, search pagination, data exports, and more.
Account takeover (ATO): targets active user accounts and causes service disruptions, widespread account lockouts, and prevents customers from using your service. ATO is often executed via malicious bots and wide-scale credential stuffing.
Brute force attacks: repeated request attempts to guess valid credentials or input parameters in order to obtain unauthorized access to the application functionality or data. Examples include username / password guessing against an app’s authentication and enumeration of user profiles and web server directories.
Content scraping: a type of bot attack where web page content is harvested by fraudsters for use elsewhere. Also done for competitive reconnaissance to ensure a retailer is charging the lowest price for products or other similar reasons.
Form submission abuse: a bot attack where forms on public-facing websites are abused for a variety of malicious reasons. For instance, they might perform SQLi, scanning, or post unwanted content through these forms.
Server Side Request Forgery (SSRF): an application or API is tricked into sending a request to another backend service, either over the internet or across the network the server is hosted on, to retrieve information from that service and relay it back to the attacker.
Disallowed traffic sources: API abuse from known malicious sources (Tor, data centers, etc) or from disallowed countries and geographies.
HTTP request smuggling: many modern web applications use chains of front-end and back-end HTTP servers to process user requests. Request smuggling involves attackers modifying one of those requests to trick the backend systems into processing a request incorrectly. This can lead to attacks such as cache poisoning or can enable attackers to compromise an application by bypassing other security controls.
Additional attacks on web applications and APIs include:
- Unintentional API Overuse
- Partner API misuse
- Insider threats
- Weak TLS Protocols / Ciphers
- Session hijacking
How to deploy a Web Application and API Protection solution
A WAAP service should be easily and quickly deployed within the infrastructure you’ve already invested in. Signal Sciences WAAP Platform can be installed in many ways, depending on your application design and infrastructure.
| Infrastructure | API Gateways | SIEM/SOC | DevOps Toolchain |
|---|---|---|---|
|
|
|
|
A WAAP solution should support any infrastructure and multiple programming languages. Examples include:
| Infrastructure | Languages | |
|---|---|---|
|
|
|