Qodana
The code quality platform for teams
What Is the OWASP Top 10 and How Can Your Team Benchmark Security?
Businesses of different sizes have various motives for prioritizing code security. For an enterprise client, it might have to do with compliance. For a business that handles user data, there could be very imminent risk to customers and staff alike.
Any development team could fall prey to the rise of cybercrime and attacks as detailed in the CyberCrime Report and many other sources. This is one reason why it’s so important to secure your codebase against both seemingly simple and more sophisticated and malicious activity.
Then again, it’s easy to say that developer teams need to prioritize security, but this is sometimes difficult to put into practice. What frameworks are most helpful? Can they be applied to teams of any size and industry? And which standards do developers trust to help them achieve a level of foundational security and safety?
Table of Contents
What is OWASP?
The Open Web Application Security Project (OWASP) is an organization dedicated to improving software security. One of its primary contributions is the OWASP Top 10, which outlines the most critical security risks to web applications and provides the checks that organizations should consider when enhancing application security. While OWASP hasn’t officially released the list for 2025, we’re taking a closer list of some common contenders today. Let’s dive in:
Common OWASP Top 10 checks
SQL Injection
SQL Injection (SQLi) is a type of injection attack where an attacker can execute arbitrary SQL code on a database by manipulating the SQL queries made by an application.
How it happens:
SQLi typically happens when user inputs are directly included in SQL statements without proper validation or escaping. For example:
SELECT * FROM users WHERE username = ‘user_input’;
If user_input is not sanitized, an attacker could input something like admin’ –, which might change the original query’s logic.
Prevention is better than cure
To prevent this, you could use prepared statements with parameterized queries to separate SQL logic from user input. Stored procedures are precompiled SQL statements that can accept parameters. Always validate and sanitize user inputs.
Ensure that only expected values are accepted (e.g., alphanumeric validation) and avoid displaying detailed error messages to users, which could give attackers insights into the database structure. The database account used by the application should have no more privileges than necessary, that way one can at least reduce the impact if an SQL injection is successful.
You also get Command Injections, which the attacker manages to execute arbitrary commands on the host operating system via a vulnerable application. For example, an attacker might input ; rm -rf / to execute unauthorized commands. To prevent these you should avoid executing system commands, use safe, language-specific APIs that don’t invoke command shells, and if user inputs have to be included in a command shell, make sure that inputs are properly escaped.
Qodana’s Taint Analysis helps prevent security vulnerabilities like SQL injections, cross-site scripting (XSS), command injections, and path traversal and is supported in IntelliJ IDEA as well as in Qodana for Php and JVM.
Broken Authentication
Check for Broken Authentication aims to address vulnerabilities in user authentication processes and session management that can lead to a range of security risks.
You can address this by implementing Multi-Factor Authentication (MFA) and making sure sessions are securely managed. MFA is a security mechanism that requires users to use two or more independent credentials to verify their identity.
Instead of just relying on a username and a password, which can be stolen, guessed, or brute-forced, MFA adds extra layers of security that make authentication more secure with biometric, device, or knowledge entries. If you use this in conjunction with secure session management, you have a good starting point for better and more secure authentication.
Prevention measures
It matters how applications handle user sessions over the duration of their interactions with the system. When users log in an application, the application creates a session (or token) to keep track of their authenticated status. The identifiers for these have to be unique and transmitted securely using HTTPS to encrypt data between the client and the server.
Sensitive data exposure
Sensitive data can include personal information (PII), payment information, healthcare records, authentication credentials, and any other data that could be harmful if exposed.
To combat this, developers need to encrypt data in transit over networks and “at rest”, i.e. stored on servers and databases.
You can do this by generating cryptographic keys that use secure, random sources and only allow authorized people and applications to access them. Never hard-code keys in the application or configuration files. You can also implement a key rotation policy.
Also keep in mind that Hardcoded secrets are related to several items in the OWASP Top 10, particularly “Sensitive Data Exposure” and “Broken Authentication.” Detecting hardcoded passkeys helps to mitigate risks associated with these vulnerabilities.
XML External Entities (XXE)
XML External Entities (XXE) is a vulnerability that happens when an XML parser doesn’t process external entity references properly. Attackers can exploit this vulnerability for:
Data exfiltration: Attackers can manipulate an XML input to read sensitive files from the server or sensitive information from other places.
Denial of Service (DoS): By including a large number of entities in the XML file, an attacker can cause the application to consume excessive resources, leading to service outages.
Server Side Request Forgery (SSRF): Attackers can access internal services and resources which are not directly accessible from the outside world.
The best way to mitigate XXE vulnerabilities is to entirely disable the external entities being processed. This can usually be configured in the XML parsing libraries that your application is using.
For example, if you’re using Java with DOM or SAX parsers, you can configure them to disable DTD processing and external entities:
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setValidating(false);
dbf.setFeature(“http://xml.org/sax/features/external-general-entities”, false);
dbf.setFeature(“http://xml.org/sax/features/external-parameter-entities”, false);
dbf.setFeature(“http://apache.org/xml/features/disallow-doctype-decl”, true);
You can also implement strict validation and schema checks for XML inputs. This process ensures that the XML data adheres to a predefined structure and is what your application expects.
Broken Access Control
Role-Based Access Control (RBAC) is a widely used method for restricting system access to authorized users. In RBAC, permissions are assigned based on roles rather than individual users, which helps streamline the management of user access. However, without proper implementation and regular testing, systems can become vulnerable.
Get ahead of access issues
Clearly define roles based on job responsibilities and least privilege principles. Ensure roles align closely with user needs and limit permissions to what is strictly necessary. Some organizations may need to define hierarchical roles. For instance, a manager could inherit the permissions of their subordinates, but without additional privileges that they do not require.
Conduct periodic reviews of roles and permissions to ensure they remain relevant and appropriate. Consider any role changes in personnel or shifts in organizational processes. Implement temporary or context-sensitive roles for particular tasks or projects. This way, users can gain additional permissions as needed without permanently extending their permissions.
Maintain detailed logs of access attempts and regularly monitor these logs for any suspicious activity. This can help you spot any causes for concern like unwanted access.
Control testing is another important tactic to help identify potential vulnerabilities like horizontal (same level access) and vertical (higher-level access) privileges.You can use automated security testing tools that can simulate various attack vectors to check for access control weaknesses. Tools can be used to check access control lists (ACLs) and role permissions programmatically.
Security Misconfiguration
Improper security configurations are one of OWASP’s major checks because default settings can create security risks.
To prevent this, change any default passwords right after installing new systems. Those default passwords are often widely known and can be a goldmine for attackers.
Also, many applications and operating systems come with unnecessary services turned on by default, so go through and turn off those unused features to decrease vulnerabilities. Also make sure that default roles and access permissions aren’t giving users more access than they really need.
Also, apply security hardening guidelines for servers, databases, and applications to eliminate unnecessary features and reduce attack surfaces.
And keep in mind that before deploying patches to production systems, it’s important to test them in a staging environment to identify any potential compatibility issues or bugs that could arise from the update.
Cross-Site Scripting (XSS)
Cross-Site Scripting (XSS) is a type of security vulnerability that allows an attacker to inject malicious scripts into content delivered to users’ web browsers. When a user visits a page that contains XSS, the malicious script can execute within the context of that user’s session, leading to various risks, including data theft, session hijacking, or defacement of web applications.
Mitigating cross-site scripting risk
Mitigate this issue with output encoding to ensure that user inputs are properly encoded before they’re visible and only show up as plain text. You could do this by converting characters into their HTML equivalents, encoding characters that are specific to HTML attributes like “ and in JavaScript properly escaping a user input so that it won’t execute the script. You could also implement a content security policy to mitigate the risk of XSS attacks.
If you’re using IntelliJ IDEA, you can use the Qodana plugin to find and address cross-site scripting. Find it under the Problems tab in the Security Analysis section.
Insecure deserialization
Insecure deserialization occurs when an application accepts data from untrusted sources and interprets it as a serialized object without proper validation. This opens the door for attackers to manipulate the serialized data, potentially leading to remote code execution, data tampering, or denial-of-service attacks.
Mitigate these risks
Avoid deserializing untrusted data altogether. If deserialization is necessary, developers should implement stringent checks to validate the integrity and format of the incoming data. Using safe serialization formats, which don’t allow for arbitrary code execution, can hugely reduce the risks associated with processing untrusted data.
Integrity checks also play a big role in securing serialized data. Digital signatures or cryptographic hashes allow an application to verify that the serialized object has not been altered in any way it’s not supposed to be.
By signing serialized data with a private key, the application can later check the signature against the expected outcome using a public key, helping to ensure the data’s authenticity. Also, using hashes enables the application to confirm that the data remains unchanged. However, even with integrity checks, deserializing data from untrusted sources should be minimized or avoided.
OWASP guidance in a nutshell
Secure your application development and deployment more thoroughly by using these checks as a security benchmark. Regular security testing, code reviews, and security training for developers play a crucial role in minimizing risks associated with these vulnerabilities.
If you are implementing OWASP standards, consider using resources like the OWASP Cheat Sheets, OWASP Testing Guide, and OWASP Best Practices for secure coding. You can also use Qodana to look for issues and run select security checks in your CI/CD pipeline.
Join the discussion
Keep a eye on X or JetBrains Bluesky for the announcement of our Taint Analysis roundtable – coming soon!
Subscribe to Qodana Blog updates
