Java Application Security: Top 10 Vulnerabilities for Beginners

Java Application Security: Top 10 Vulnerabilities for Beginners

Java remains one of the most popular languages for building enterprise and web applications. However, even a reliable platform does not guarantee code security. According to OWASP, most breaches occur due to developer errors, not vulnerabilities in the JVM. In this article, we will cover the top 10 Java application vulnerabilities that every beginner developer should know. You will gain not only theoretical knowledge but also practical code examples with explanations on how to avoid dangerous mistakes.

1. SQL Injection

The most common threat. An attacker can execute arbitrary SQL queries if you concatenate strings directly.

Bad example (vulnerable code):

String query = "SELECT * FROM users WHERE username = '" + userName + "' AND pass = '" + password + "'";\nStatement stmt = connection.createStatement();\nResultSet rs = stmt.executeQuery(query);

Solution: use PreparedStatement with parameterized queries.

String query = "SELECT * FROM users WHERE username = ? AND pass = ?";\nPreparedStatement pstmt = connection.prepareStatement(query);\npstmt.setString(1, userName);\npstmt.setString(2, password);\nResultSet rs = pstmt.executeQuery();

2. Cross-Site Scripting (XSS)

If you output user data into HTML without escaping, an attacker can inject JavaScript code.

Vulnerable code (JSP):

<%= request.getParameter("message") %>

Protection: escape output using libraries (e.g., OWASP Java Encoder) or use template engines with auto-escaping (Thymeleaf, JSP with JSTL).

<c:out value="${message}" />

3. Insecure Deserialization

Java deserialization can lead to remote code execution (RCE) if an attacker sends a specially crafted byte stream.

Bad practice:

ObjectInputStream ois = new ObjectInputStream(socket.getInputStream());\nObject obj = ois.readObject(); // anything can be restored

Recommendations:

\n
• Never deserialize data from untrusted sources.
\n
• Use class whitelists (look-ahead object input stream).
\n
• Consider alternatives (JSON, Protobuf).
\n

4. Command Injection

If your application calls system commands with user data, injection is possible.

Dangerous code:

Runtime.getRuntime().exec("ping " + userInput); // userInput = 127.0.0.1; rm -rf /

Protection: avoid calling shell commands, use built-in Java libraries. If a call is unavoidable — validate input with a strict whitelist.

5. Authentication and Session Management Flaws

Weak session protection is a common issue. For example, using predictable session IDs or storing passwords in plain text.

\n
• Generate session IDs using SecureRandom.
\n
• Use modern hashing (bcrypt, scrypt, Argon2) for passwords.
\n
• Set session timeouts and HttpOnly/Secure flags for cookies.
\n

6. Security Misconfiguration

Leftover debug modes, default passwords, open ports — all of this gives an attacker information about the system.

What to check in Spring Boot:

\n
• Disable Actuator endpoints in production or secure them.
\n
• Do not use spring.jpa.show-sql=true in production.
\n
• Remove default server headers