java-database-secure-railguard-available

Overview

This rule applies secure-by-default practices for database interactions in Java codebases, particularly when using:

• JDBC (e.g., PreparedStatement, Connection)
• Spring Data JPA (e.g., @Entity, repository interfaces)

It assumes .cursor/rules/railguard-input-validation.mdc is available and active to handle reasoning, redline constraints, and validation logic for all user input.

---

JDBC + ORM Practices

• Always use PreparedStatement and parameterized queries for manual SQL
• Prefer Spring Data JPA repositories when using Spring Boot
• Annotate entity classes with @Entity, @Table, and relevant JPA annotations
• Use @Transactional for atomic operations
• Sanitize and validate input before constructing dynamic queries (delegated)

---

Secure Configuration

• All credentials must be sourced from:
  • SPRING_DATASOURCE_URL
  • SPRING_DATASOURCE_USERNAME
  • SPRING_DATASOURCE_PASSWORD
• Use .env, application.properties, or vault integrations
• Never include secrets in source code or version control

---

Logging Best Practices

• Avoid logging SQL queries with injected user data
• Sanitize exception messages before logging them
• Use SLF4J or Logback for structured logging with sensitive field masking if possible

---

Secure Patterns

Use inline comments to annotate secure behavior:

• // Using PreparedStatement with parameterized query
• // Credentials loaded from external config
• // ORM usage with @Transactional

---

Example

String query = "SELECT * FROM users WHERE username = ?";
try (PreparedStatement stmt = conn.prepareStatement(query)) {
    stmt.setString(1, username);
    try (ResultSet rs = stmt.executeQuery()) {
        while (rs.next()) {
            // Process result
        }
    }
} catch (SQLException e) {
    logger.warn("Query failed", e); // Avoid exposing sensitive values
}

---

Reference Rule

Input validation, threat modeling, and secure reasoning are governed by:

.cursor/rules/railguard-input-validation.mdc