Prevent injection by using parameterized queries, query builders, and input validation; 2. Secure authentication with Spring Security or Apache Shiro, enforce strong passwords, MFA, and secure session cookies; 3. Protect sensitive data via bcrypt/PBKDF2 for passwords, AES-256-GCM encryption, HTTPS, and sanitized logs; 4. Block XXE by disabling DTDs in XML parsers or using JSON instead; 5. Enforce broken access control using backend role-based checks with Spring Security’s @PreAuthorize and test manually; 6–10. Avoid security misconfiguration with dependency scanning, prevent XSS via output encoding, block insecure deserialization, patch vulnerable components using automated tools, and ensure sufficient logging of security events—security is a development habit, not a feature, so integrate threat modeling, code reviews, and automated scans early and consistently to address the OWASP Top 10 effectively.

Securing Java applications against the OWASP Top 10 isn’t about slapping on a few libraries or running a scanner—it’s about baking security into your development lifecycle from day one. Java’s strong ecosystem gives you powerful tools, but you still need to know how and where to apply them. Here's how to tackle the most critical risks:

1. Injection (e.g., SQL, Command, LDAP)

This is still #1 for a reason—Java apps are vulnerable if you’re concatenating strings into queries.

Fix it:

• Use parameterized queries with PreparedStatement or JPA/Hibernate named parameters.
• For dynamic queries, use query builders like JOOQ or Criteria API.
• Validate and sanitize all inputs—even if they come from "trusted" sources.

Example:
? String query = "SELECT * FROM users WHERE id = " userId;
? String query = "SELECT * FROM users WHERE id = ?"; ps.setInt(1, userId);

2. Broken Authentication

Java apps often roll their own auth logic—which is risky. Even with Spring Security, misconfigurations happen.

Fix it:

• Use Spring Security or Apache Shiro—don’t write your own session/token management.
• Enforce strong password policies (length, complexity, no reuse).
• Implement multi-factor authentication (MFA) where possible.
• Set secure session cookies: HttpOnly, Secure, and SameSite=Strict.

Pro tip:
Enable CSRF protection in Spring Security—it’s on by default but easy to accidentally disable.

3. Sensitive Data Exposure

If you’re storing passwords in plain text or using weak crypto, you’re asking for trouble.

Fix it:

• Hash passwords with bcrypt, scrypt, or PBKDF2—never MD5 or SHA-1.
• Encrypt sensitive data at rest (use JCE with AES-256-GCM).
• Use HTTPS everywhere—no exceptions. Spring Boot makes this easy with SSL config.

Don’t forget:
Log files and stack traces can leak secrets. Sanitize logs using tools like Logback filters or OWASP ESAPI.

4. XML External Entity (XXE) Processing

Common in apps that parse XML from untrusted sources—like file uploads or APIs.

Fix it:

• Disable DTDs and external entities in your XML parsers:

  DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
  dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);

• Or switch to JSON—it’s simpler and safer for most use cases.

5. Broken Access Control

Just because someone is logged in doesn’t mean they should see everything—this is where role-based checks fail silently.

Fix it:

• Enforce role-based access control (RBAC) on every request—not just the UI.
• Use Spring Security’s @PreAuthorize("hasRole('ADMIN')") on methods.
• Test access control manually—try accessing /admin as a regular user.

Real-world issue:
A common mistake is checking permissions only on the frontend. Always re-check on the backend.

6–10 (Brief but Critical):

• Security Misconfiguration: Use tools like OWASP Dependency-Check to scan for outdated libs. Keep Tomcat, Spring, and dependencies updated.
• Cross-Site Scripting (XSS): Escape output with OWASP Java Encoder or Thymeleaf’s th:text (auto-escapes by default).
• Insecure Deserialization: Never deserialize untrusted data. If you must, use signed objects or switch to JSON.
• Using Components with Known Vulnerabilities: Run mvn dependency:analyze and integrate OWASP Dependency-Check into CI/CD.
• Insufficient Logging & Monitoring: Log auth failures, input validation errors, and access denied events. Use structured logging (e.g., JSON logs) for easier analysis.

Bottom line:
Java gives you the tools—Spring Security, Hibernate, OWASP libraries—but security is a habit, not a feature. Start with threat modeling, code reviews, and automated scans (like SonarQube Dependency-Check), and you’ll cover 80% of the OWASP Top 10 without breaking a sweat.

The above is the detailed content of Securing Java Applications against OWASP Top 10. For more information, please follow other related articles on the PHP Chinese website!