What You Will Learn
- 1 What is OWASP?
- 2 The OWASP Top 10
- 3 Understanding and Preventing Common OWASP Attacks
- 4 Injection
- 5 Broken Authentication
- 6 Sensitive Data Exposure
- 7 XML External Entities (XXE)
- 8 A5. Broken Access Control
- 9 Other OWASP Top 10 Attacks
- 10 Imperva Application Security
What is OWASP?
The Open Web Application Security Project (OWASP) is a non-profit organization founded in 2001, with the goal of helping website owners and security experts protect web applications from cyber attacks. OWASP has 32,000 volunteers around the world who perform security assessments and research.
Among OWASP’s key publications are the OWASP Top 10, discussed in more detail below; the OWASP Software Assurance Maturity Model (SAMM), the OWASP Development Guide, the OWASP Testing Guide, and the OWASP Code Review Guide.
See how Web Application Firewall can help you with OWASP Top 10 attacks.
The OWASP Top 10
OWASP Top 10 is a widely accepted document that prioritizes the most important security risks affecting web applications. Although there are many more than ten security risks, the idea behind the OWASP Top 10 is to make security professionals keenly aware of at least the most critical security risks, and learn how to defend against them.
OWASP periodically evaluates important types of cyber attacks by four criteria: ease of exploitability, prevalence, detectability, and business impact, and selects the top 10 attacks. The OWASP Top 10 was first published in 2003 and has since been updated in 2004, 2007, 2010, 2013, and 2017.
Understanding and Preventing Common OWASP Attacks
Below is information provided by the OWASP foundation on five important web application attacks which usually rank in the top half of the OWASP Top 10, how they manifest themselves, and how you can protect your organization against them. Code examples are taken from the OWASP Top 10 guidelines.
An injection vulnerability in a web application allows attackers to send hostile data to an interpreter, causing that data to be compiled and executed on the server. A common form of injection is SQL injection.
Examples of Injection Attacks
An application uses untrusted data when constructing a vulnerable SQL call:
String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";
An application trusts a framework without sanitizing its inputs, in this case Hibernate Query Language (HQL):
Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");
The attacker modifies the ‘id’ parameter in their browser to send code. For example:
http://example.com/app/accountView?id=' or '1'='1
This causes the queries to return all the records from the accounts table and can be used to perform other malicious actions on the server.
Preventing Injection Attacks
- Use a safe API which avoids the use of the interpreter entirely
- Use positive or “whitelist” server-side input validation
- Escape special characters
- Use LIMIT and other SQL controls within queries to prevent mass disclosure of records in case of SQL injection.
A web application with broken or weak authentication can be easily detected by attackers and is vulnerable to brute force/dictionary attacks and session management attacks
Examples of Broken Authentication Attacks
- Credential stuffing━attackers use lists of known passwords and try them sequentially to gain access. Without automated threat or credential stuffing protection, the application is used by attackers as a validation mechanism for any password they try.
- Password-based attacks━web applications relying only on passwords have inherently weak authentication mechanisms, even if passwords have complexity requirements and are rotated. Organizations should switch to multi-factor authentication.
Mitigating Broken Authentication
- Implement multi-factor authentication
- Do not deploy systems with default credentials
- Check for a list of the top 10,000 worst passwords
- Use the guidelines in NIST 800-63 B section 5.1.1 for Memorized Secrets
- Harden all authentication-related processes like registration and credential recovery
- Limit or delay failed login attempts
- Use a secure, built-in, server-side session manager
Sensitive Data Exposure
Sensitive data is typically the most valuable asset targeted by cyber attacks. Attackers can gain access to it by stealing cryptographic keys, conducting “man in the middle” (MITM) attacks, or stealing cleartext data which may occasionally be stored on servers or user browsers.
Examples of Sensitive Data Exposure
- No TLS━if a website does not use SSL/TLS for all pages, an attacker can monitor traffic, downgrade connections from HTTPS to HTTP and steal the session cookie.
- Unsalted hashes━a web application’s password database can use unsalted or simple hashes to store passwords. If an attacker gains access to the database they can easily crack the hashes, for example using GPUs, and gain access.
Mitigating Sensitive Data Exposure
- Identify sensitive data and apply appropriate security controls.
- Don’t store sensitive data unless absolutely needed━discard sensitive data, use tokenization or truncation.
- Encrypt all sensitive data at rest using strong encryption algorithms, protocols and keys.
- Encrypt data in transit using secure protocols like TLS and HTTP HSTS.
- Disable caching for sensitive data.
- Store passwords using strong, salted hashing functions like Argon2, scrypt and bcrypt.
XML External Entities (XXE)
If a web application uses a vulnerable component processing XML, attackers can upload XML or include hostile content, commands or code within an XML document.
XXE Attack Examples
An attacker can use this XML code to extract data from the server:
An attacker can obtain information about a private network by changing the ENTITY line to:
Mitigating XXE Attacks
- Use simpler data formats like JSON and avoid serialization
- Patch or upgrade all XML processors and libraries
- Disable XML external entity and DTD processing
- Implement whitelisting and sanitization of server-side XML inputs
- Validate XML using XSD or similar validation
- Use SAST tools to detect XXE in source code, with manual review if possible
A5. Broken Access Control
Broken access control means that attackers can gain access to user accounts and act as users or administrators, and that regular users can gain unintended privileged functions. Strong access mechanisms ensure that each role has clear and isolated privileges.
Broken Access Control Examples
An application can accept an SQL call requesting account information, without verifying it:
pstmt.setString(1, request.getParameter("acct")); ResultSet results = pstmt.executeQuery( );
The attacker can change the ‘acct’ parameter to get access to any account number they want:
Mitigating Broken Access Control
- Deny access by default, except for public resources
- Build strong access control mechanisms and reuse them across the application
- Enforce record ownership━don’t allow users to create, read or delete any record
- Enforce usage and rate limits
- Disable server directory listing and do not store metadata or backup files in the folder root
- Log failed access attempts and alert admins
- Rate limit API and controller access
- Validate JWT tokens after logout
Other OWASP Top 10 Attacks
- Security Misconfigurations━misconfigured security controls are a common entry point for attackers. For example, a database deployed with a default admin password.
- Cross-Site Scripting (XSS)━attackers use XSS to exploit weaknesses in session management and execute malicious code on user browsers.
- Insecure Deserialization━deserialization is a complex technique, but if executed correctly, it allows attackers to execute malicious code on a server.
- Using Components with Known Vulnerabilities━most web applications rely heavily on open-source components, and these may include known vulnerabilities that attackers can exploit to gain access or cause damage.
- Insufficient Logging and Monitoring━attackers rely on the lack of monitoring and timely response to succeed with any other attack vector.
Imperva Application Security
Imperva’s industry-leading Web Application Firewall (WAF) provides robust protection against OWASP Top 10 attacks and other web application threats. offers two WAF deployment options:
- Cloud WAF—permit legitimate traffic and prevent bad traffic. Safeguard your applications at the edge with an enterprise‑class cloud WAF.
- Gateway WAF—keep applications and APIs inside your network safe with Gateway WAF.
In addition to WAF, provides multi-layered protection to make sure websites and applications are available, easily accessible and safe. The application security solution includes:
- DDoS Protection—maintain uptime in all situations. Prevent any type of DDoS attack, of any size, from preventing access to your website and network infrastructure.
- CDN—enhance website performance and reduce bandwidth costs with a CDN designed for developers. Cache static resources at the edge while accelerating APIs and dynamic websites.
- Bot management—analyzes your bot traffic to pinpoint anomalies, identifies bad bot behavior and validates it via challenge mechanisms that do not impact user traffic.
- API security—protects APIs by ensuring only desired traffic can access your API endpoint, as well as detecting and blocking exploits of vulnerabilities.
- Account takeover protection—uses an intent-based detection process to identify and defends against attempts to take over users’ accounts for malicious purposes.
- RASP—keep your applications safe from within against known and zero‑day attacks. Fast and accurate protection with no signature or learning mode.
- Attack analytics—mitigate and respond to real security threats efficiently and accurately with actionable intelligence across all your layers of defense.