Lessons from Real Spring Boot Security Assessments: Vulnerable Code Patterns, Risks, and Mitigations

Introduction

Over the last decade, Spring Boot has become one of the most widely adopted frameworks for building enterprise applications.

Its popularity brings significant benefits:

• Rapid development
• Strong ecosystem
• Cloud-native readiness
• Enterprise-grade capabilities

However, popularity also attracts attackers.

A review of penetration testing reports, bug bounty disclosures, CVEs, and OWASP findings reveals an important reality:

Most Spring Boot breaches are not caused by flaws in Spring itself.

They are caused by insecure implementation decisions made by developers.

This article examines common vulnerability patterns observed in real-world Spring Boot applications and discusses secure alternatives.

---

The Security Pyramid

Many developers assume security begins with:

Spring Security

In reality:

Secure Design
↓
Secure Code
↓
Secure Dependencies
↓
Secure Configuration
↓
Secure Infrastructure

A security filter alone cannot protect vulnerable business logic.

---

Vulnerability #1: SQL Injection

Vulnerable Code

String sql =
    "SELECT * FROM users WHERE email='"
    + email + "'";

jdbcTemplate.queryForList(sql);

Why is this dangerous?

User input becomes part of the SQL statement.

Attackers may manipulate the query structure and access unintended data. SQL injection remains one of the most common application security issues.

---

Secure Version

String sql =
    "SELECT * FROM users WHERE email=?";

jdbcTemplate.queryForList(sql, email);

Or better:

Spring Data JPA

with parameterized repository methods.

Mitigation

• Prepared statements
• Parameterized queries
• JPA repositories
• Input validation
• Least-privilege database accounts

---

Vulnerability #2: Broken Access Control

One of the most dangerous API vulnerabilities.

Example:

@GetMapping("/users/{id}")
public User getUser(
        @PathVariable Long id) {

    return userRepository.findById(id);
}

Problem:

A user may request another user's record if ownership checks are missing.

---

Secure Version

if(!currentUser.owns(id)) {
    throw new AccessDeniedException();
}

Always validate authorization at the server side.

Broken access control remains among the most prevalent web application risks.

---

Vulnerability #3: Exposed Actuator Endpoints

A surprisingly common finding during penetration testing.

Example configuration:

management.endpoints.web.exposure.include=*

This may expose:

/actuator/env
/actuator/heapdump
/actuator/mappings

Depending on configuration.

These endpoints can reveal sensitive operational information and have been involved in recent Spring-related security advisories.

---

Recommended Configuration

management.endpoints.web.exposure.include=health,info

Additionally:

• Restrict access
• Use network controls
• Authenticate management endpoints

---

Vulnerability #4: Hardcoded Secrets

Example:

String password =
    "admin123";

or

aws.secret.key=abcd1234

Common consequences:

• Cloud account compromise
• Database compromise
• Service impersonation

---

Better Approach

Use:

• Environment variables
• Secret managers
• Vault solutions
• Cloud-native key stores

Examples:

• Azure Key Vault
• AWS Secrets Manager

---

Vulnerability #5: Unsafe Deserialization

Deserialization vulnerabilities have led to numerous Java security incidents.

Example:

ObjectInputStream in =
    new ObjectInputStream(stream);

Object obj =
    in.readObject();

When untrusted data is deserialized, attackers may abuse gadget chains and vulnerable libraries. Unsafe deserialization remains a major security concern in Java ecosystems.

---

Mitigation

Avoid:

Java Native Serialization

Prefer:

• JSON
• DTO mapping
• Explicit object construction
• Serialization allowlists

---

Vulnerability #6: Insecure File Upload

Example:

file.transferTo(
    new File("/uploads/" +
    file.getOriginalFilename()));

Risks include:

• Malicious files
• Executable uploads
• Storage abuse

---

Mitigation

Validate:

• File type
• MIME type
• Extension
• Size limits

Store files outside application execution directories.

---

Vulnerability #7: Missing Rate Limiting

Example API:

POST /login

Without controls:

Attackers can repeatedly attempt authentication.

---

Recommended Controls

• Rate limiting
• CAPTCHA
• Account lockout policies
• IP throttling

Tools:

• Bucket4j
• API Gateway rate limiting
• Spring Cloud Gateway filters

---

Vulnerability #8: Sensitive Data Exposure

Common examples:

log.info(
    "User Password: {}",
    password);

or

return userEntity;

where userEntity contains:

Password Hash
SSN
Token
PII

---

Mitigation

Use DTOs.

Never expose:

• Passwords
• Secrets
• Internal identifiers
• Sensitive metadata

Sensitive data exposure remains a recurring OWASP concern.

---

Vulnerability #9: Dependency Vulnerabilities

Many Spring Boot applications contain:

Hundreds of dependencies

A secure codebase may still become vulnerable through outdated libraries.

Examples from recent years:

• Log4Shell
• Spring4Shell
• Various Jackson vulnerabilities

Spring applications pull many transitive dependencies, making dependency management critical.

---

Recommended Practice

Integrate:

OWASP Dependency Check

into CI/CD.

Automate:

• CVE scanning
• Dependency updates
• Vulnerability reporting

---

Vulnerability #10: Security Misconfiguration

Examples:

spring.h2.console.enabled=true

in production.

Or:

server.error.include-stacktrace=always

Risks:

• Information leakage
• Reconnaissance assistance
• Misconfiguration exploitation

Security misconfiguration consistently appears in OWASP risk categories.

---

The Most Dangerous Vulnerability: Trusting the Frontend

Many developers unintentionally assume:

Frontend Validation
=
Security

This is false.

Attackers interact directly with APIs.

Every validation rule must be enforced server-side.

Always assume:

Client Input
=
Untrusted Input

---

Secure Spring Boot Development Checklist

Before deployment:

Authentication

✅ Strong password policies

✅ MFA where possible

✅ JWT validation

---

Authorization

✅ Role-based access control

✅ Object-level authorization

---

Input Validation

✅ Bean Validation

✅ DTO validation

✅ Parameter constraints

---

Dependencies

✅ Automated CVE scanning

✅ Dependency upgrades

---

Secrets

✅ Externalized secrets

✅ Rotation policies

---

Logging

✅ Security events logged

✅ Sensitive data masked

---

Infrastructure

✅ HTTPS everywhere

✅ WAF protection

✅ Network segmentation

---

Architect's Perspective

Most organizations focus on finding vulnerabilities.

Mature organizations focus on preventing classes of vulnerabilities.

Instead of asking:

"How do we fix SQL Injection?"

Ask:

"How do we eliminate dynamic SQL entirely?"

Instead of:

"How do we detect leaked secrets?"

Ask:

"How do we prevent secrets from entering source code?"

The shift from reactive security to secure-by-design architecture is where true maturity begins.

---

Conclusion

The majority of Spring Boot security incidents arise not from weaknesses in Spring itself, but from insecure coding patterns, misconfigurations, and dependency management failures.

The most effective security strategy combines:

• Secure coding
• Secure architecture
• Automated scanning
• Continuous monitoring
• Developer education

Technology changes.

Attack techniques evolve.

But the principle remains constant:

Secure systems are built deliberately, not accidentally.

For Spring Boot teams, security should be treated as a design requirement from the first line of code rather than a penetration testing exercise before release.