OWASP Top 10: how to discover vulnerabilities in your Java applications

In this article you will learn which are the top 10 security issues in web applications (called OWASP TOP 10). For each vulnerability you will get how to know if your code is protected against it and how to analyze it automatically.


What’s OWASP Top 10?

OWASP is an open community dedicated to enabling organizations to conceive, develop, acquire, operate and maintain applications that can be trusted.

OWASP is an international non-profit organization dedicated to analyzing, documenting and spreading the principles for the safe and vulnerability-free software development. They produce a document called OWASP Top 10. As they say: “The OWASP Top Ten is a powerful awareness document for web application security. The OWASP Top Ten represents a broad consensus about what the most critical web application security flaws are. Adopting the OWASP Top Ten is perhaps the most effective first step towards changing the software development culture within your organization into one that produces secure code“.

Financial injection
Creative commons image from Doug88888

How can I detect vulnerabilities in my application?

The origin of OWASP vulnerabilities can be in any component involved in a web application production system, such as servers, network and connections security, accesses to related systems, etc. However, most of them can be prevented by writing source code which is secure and protected against potential threats. Kiuwan may help to detect insecure code that could be corrected to prevent a security problem in the future. Let’s review the OWASP TOP TEN to check which ones can be detected in coding phase using Kiuwan rules:

  • A1 Injection. Injection flaws, such as SQL, OS and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

There are several Kiuwan rules to verify that your code is not vulnerable to the most common security problem:

    • OPT.JAVA.SEC_JAVA.LdapInjectionRule: Avoid non-neutralized user-controlled input in LDAP search filters.
    • OPT.JAVA.SEC_JAVA.SqlInjectionRule: Avoid SQL code formed with non neutralized user input. More.
    • OPT.JAVA.SEC_JAVA.CommandInjectionRule: Avoid non-neutralized user-controlled input composed in a SO command.


If you’re curious about the #1 security issue, you can watch this tutorial:


  • A2 Broken authentication and session management. Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys or session tokens, or to exploit other implementation flaws to assume other users’ identities.

Kiuwan provides several rules to verify the correct use of Java sessions and authentication:

    • OPT.JAVA.SEC_JAVA.RequestParametersInSessionRule: Request parameters should not be passed into Session without sanitizing.
    • OPT.JAVA.SEC_JAVA.InsufficientSessionExpirationRule: Check if that session expiration interval is positive and if it does not exceed a limit.
    • OPT.JAVA.SEC_JAVA.AvoidJ2EENonSerializableObjectsStored: Avoid non-serializable objects stored in session in J2EE applications.
    • OPT.JAVA.SEC_JAVA.WebXmlSecurityMisconfigurationsRule: Many web sites use SSL for authentication, but then either revert back to non-SSL for subsequent communication or have parts of the site that can still be accessed via non-SSL. This leaves the session coookie (i.e. JSESSIONID) vulnerable to session hijacking attacks. To prevent this, session cookies can be created with the “Secure” flag, which ensures that the browser will never transmit the specified cookie over non-SSL.
    • OPT.JAVA.SEC_JAVA.AcegiRunAsAuthenticationReplacementRule: Using the Run-As authentication replacement feature in Acegi can lead to a privilege escalation vulnerability.


  • A3 Cross site scripting (XSS). XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

Most rules of the previous point prevent cross site scripting problems. But Kiuwan provides more:

    • OPT.JAVA.SEC_JAVA.CrossSiteScriptingRule: Improper neutralization of input during web content generation (Cross-site Scripting, XSS).
    • OPT.JAVA.SEC_JAVA.UnsafeCookieRule: HttpOnly, for example, could mitigate some CSRF (cross-site request forgery) issues as it makes more difficult for the attacker to capture sensitive cookies from client-side code generated by exploiting an XSS vulnerability in a web application.
    • OPT.JAVA.SEC_JAVA.HttpSplittingRule: Improper neutralization of CR/LF Sequences in HTTP headers.


  • A4 Insecure direct object References. A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.

Code application should protect unauthorized data access. Kiuwan helps with these rules:

    • OPT.JAVA.SEC_JAVA.PathTraversalRule: Software uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the software does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location outside the restricted directory.
    • OPT.JAVA.SEC_JAVA.AnonymousLdapBindRule: Without proper access control, executing an LDAP statement that contains a user-controlled value can allow an attacker to access unauthorized records. Executing LDAP queries under an anonymous bind, effectively without authentication, can allow an attacker to abuse a poorly configured LDAP environment.


  • A5 Security misconfiguration. Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server and platform. Secure settings should be defined, implemented and maintained, as defaults are often insecure. Additionally, software should be kept up to date.

Prevent this vulnerability requires paying attention to the source code, but you can also keep in mind:

    • OPT.JAVA.SEC_JAVA.WebXmlSecurityMisconfigurationsRule: Avoid misconfiguring security properties in web.xml descriptor. The rule checks 7 common misconfigurations in web.xml descriptors:
      • No default error pages for 404/500 error codes and for uncaught exceptions.
      • No methods in security constraints.
      • Configure SSL for protected areas.
      • Send session ID under SSL only.
      • Send session cookies with the HttpOnly flag set.
      • Use cookies, not URL rewriting, to exchange session IDs with browsers.
      • Expire sessions with no too large timeouts.
    • OPT.JAVA.SEC_JAVA.AcegiInsecureChannelMixingRule. Acegi Misconfiguration – Insecure Channel Mixing. Allowing users to jump between HTTP and HTTPS leaves the application vulnerable to session hijacking.


  • A6 Sensitive data exposure. Many web applications do not properly protect sensitive data, such as credit cards, tax IDs and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.

To protect sensitive data exposure, you must use secure protocols, like HTTPS. Kiuwan can help finding misconfigurations, as I mentioned before, with rules

like OPT.JAVA.SEC_JAVA.AcegiInsecureChannelMixingRule or OPT.JAVA.SEC_JAVA.WebXmlSecurityMisconfigurationsRule.

  • A7 Missing function level access control. Most web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge them in order to access functionality without proper authorization.

Unfortunately, there is no reliable way of ensuring that each function is accessed by the appropriate user (based on their permission level), reviewing only the source code. This vulnerability, which depends closely on the functional requirements, shall be verified by functional and safety tests.


  • A8 Cross site request forgery (CSRF). A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests considered as legitimate requests from the victim by the vulnerable application.

As I commented in A3 and A5, Kiuwan can detect misconfigurations as:

    • OPT.JAVA.SEC_JAVA.UnsafeCookieRule: HttpOnly, for example, could mitigate some CSRF (cross-site request forgery) issues as it makes more difficult for the attacker to capture sensitive cookies from client-side code generated by exploiting an XSS vulnerability in a web application.


  • A9 Using components with known vulnerabilities. Components, such as libraries, frameworks and other software modules, almost always, run with full privileges. If a vulnerable component is exploited, such attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts.

Kiuwan detects and informs you about the use of dangerous J2EE API:

    • OPT.JAVA.SEC_JAVA.ESAPIBannedRule: OWASP ESAPI Secure Coding Guidelines (ESAPI SCG) include a set of banned APIs in J2EE framework and recommends replacing them by equivalent, more secure replacements.


  • A 10 Unvalidated redirects and forwards. Web applications frequently redirect and forward users to other pages and websites and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites or use forwards to access unauthorized pages.

The same rule used in the A9 is used here:

    • OPT.JAVA.SEC_JAVA.ESAPIBannedRule: Avoid dangerous J2EE API, use replacements from security-focused libraries (like OWASP ESAPI).
      • BAN011 – ServletResponse.sendRedirect(), replace by HTTPUtilities.safeSendRedirect().
      • BAN012 – RequestDispatcher.forward(), replace by HTTPUtilities.safeSendForward().


Remember that you can start using Kiuwan without charge starting today. I recommend that you sign up and begin to test whether your code is free of vulnerabilities. If you want to start testing with other code, OWASP provides you with an application called WebGoat. It is a deliberately insecure web application maintained by OWASP designed to teach web application security lessons. You can try to analyze the Java source code of WebGoat.