Secure code review of Java applications and code
By Admin
•
November 9, 2025
1. Preparation
Before touching the code:
- Understand the architecture: frameworks (Spring Boot, Struts, JSP, Servlets), libraries, and data flows.
- Identify trust boundaries: where input enters (HTTP, APIs, files) and where sensitive data exits (DB, logs, APIs).
- Get the threat model: STRIDE or equivalent to know what threats matter most.
- Know what's in scope: is it full app, a module, or specific endpoints?
Deliverable: Threat map + codebase structure outline.
2. Set Up Environment
- Clone repo and build it locally (mvn clean install or gradle build).
- Enable static analysis:
- SAST: CodeQL, FindSecBugs, SonarQube, or Checkmarx.
- Dependency checks: OWASP Dependency-Check, Snyk, or Trivy.
- Load findings but don't trust tools blindly — they're signal amplifiers, not truth.
3. Manual Code Review Strategy
Target high-risk areas first.
Area | What to Look For | Example |
Input Validation | Direct use of request params | request.getParameter("user") without sanitization |
Output Encoding | HTML, JSON, or SQL output | Missing Encode.forHtml() or PreparedStatement |
Authentication/Session | Custom login logic | Plain password compares, missing session timeouts |
Access Control | Missing annotations | No @PreAuthorize / @RolesAllowed in APIs |
Cryptography | Weak ciphers or static keys | AES/ECB, hardcoded secrets |
File Uploads | Path traversal, ZIP bomb | No normalize() on file paths |
Deserialization | Untrusted ObjectInputStream | new ObjectInputStream(inputStream) |
Logging | Sensitive data in logs | Logging passwords or tokens |
Error Handling | Info leaks | Stack traces returned in API responses |
External Calls (SSRF) | Unsanitized URLs | Using new URL(userInput) |
4. Framework-Specific Checks
For Spring Boot apps:
- Use @Valid + bean validation annotations (@NotNull, @Pattern) for request models.
- Ensure @ControllerAdvice for global exception handling.
- Confirm CSRF is enabled if app uses sessions.
- Validate @RequestParam, @PathVariable, and file uploads.
- Ensure no open actuator endpoints (/env, /metrics).
For legacy servlets/JSP:
- Review JSP for <%= userInput %> — should be replaced with <c:out>.
- Avoid scriptlets.
- Verify web.xml defines secure headers and HTTPS-only transport.
5. Automated + Manual Merge
- Combine static scan results (SARIF, XML, JSON) with your manual review notes.
- Tag findings using your risk prioritization method:
- Exploitability + Impact
- Check CISA KEV and EPSS
- CVSS only as a secondary score.
6. Remediation Review
For each critical finding:
- Provide root cause, exploit scenario, and fix recommendation.
- Validate fix by reviewing PRs or rerunning SAST.
- Check if new regressions introduced.
Example:
Finding: SQL Injection via concatenation in UserDao.javaFix: Use PreparedStatement or ORM parameter binding.Verification: Confirm commit hash abc123 replaced string concat with bound parameters.
7. Documentation
Create a clear summary:
- Key risks found
- Impact and affected modules
- Recommended mitigations
- Developer hygiene checklist
Example output:secure-code-review-report.md with findings grouped by OWASP Top 10 category.
8. Code Review Tools
- Primary: CodeQL, FindSecBugs, SonarQube.
- Auxiliary: Semgrep, Bandit (for cross-language checks).
- IDE Plugins: IntelliJ IDEA Security Plugin, FindBugs.
9. Post-Review Dev Guidance
Establish a Secure Coding Standard:
- Reference OWASP Top 10 + CWE mappings.
- Include Java code samples for safe patterns.
- Integrate pre-commit hooks or GitHub Actions for SAST.