Security Standards

26.1. Data Encryption

26.1.1. Data In-Transit

• All external communications must use TLS 1.2 or higher.
• TLS 1.0 and 1.1 must not be used.
• HTTPS is recommended for internal service-to-service communications as well.

26.1.2. Data At-Rest

• Sensitive information stored in databases (passwords, personal data) must be encrypted.
• Passwords must be hashed using the BCrypt algorithm. Plaintext storage is strictly prohibited.

@Bean
public PasswordEncoder passwordEncoder() {
  return new BCryptPasswordEncoder();
}

• Other sensitive data must be encrypted using AES-256.

26.1.3. Prohibited Algorithms

The following algorithms must not be used due to known security vulnerabilities.

Prohibited Algorithm	Reason
MD5	Vulnerable to collision attacks
SHA-1	Vulnerable to collision attacks
DES	Insufficient key length
RC4	Multiple known vulnerabilities

---

26.2. Authentication and Authorization

26.2.1. Spring Security Implementation

• All backend projects must implement Spring Security.
• Security configuration must be managed by registering a SecurityFilterChain as a Bean.

@Configuration
@EnableWebSecurity
public class SecurityConfig {

  @Bean
  public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    return http
        .csrf(csrf -> csrf.disable())
        .sessionManagement(session ->
            session.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
        .authorizeHttpRequests(auth -> auth
            .requestMatchers("/api/auth/**").permitAll()
            .requestMatchers("/api/admin/**").hasRole("ADMIN")
            .anyRequest().authenticated())
        .build();
  }
}

26.2.2. RBAC Implementation

• RBAC (Role-Based Access Control) must be implemented.
• The principle of least privilege must be followed. Only the minimum necessary permissions must be granted to users.

26.2.3. Session Management

• REST APIs must use a Stateless approach. Server-side sessions must not be used.
• Authentication tokens (JWT, etc.) must have appropriate expiration times configured.

---

26.3. Input Validation

26.3.1. Bean Validation

Bean Validation annotations must be applied to all API request DTOs.

public record CreateUserRequest(
    @NotBlank(message = "Name is required.")
    @Size(max = 50, message = "Name must be 50 characters or fewer.")
    String name,

    @NotBlank(message = "Email is required.")
    @Email(message = "Invalid email format.")
    String email,

    @NotBlank(message = "Password is required.")
    @Size(min = 8, max = 100, message = "Password must be between 8 and 100 characters.")
    String password
) {}

Use @Valid in the Controller to trigger validation.

@PostMapping("/users")
public ResponseEntity<UserResponse> createUser(@Valid @RequestBody CreateUserRequest request) {
  return ResponseEntity.status(HttpStatus.CREATED)
      .body(userService.createUser(request));
}

26.3.2. XSS Defense

• User input must be escaped when rendered in HTML.
• Vue.js double curly braces () perform escaping by default.
• The use of v-html is prohibited. If unavoidable, the content must be sanitized using a library such as DOMPurify.

26.3.3. SQL Injection Defense

• jOOQ's type-safe DSL API must be used to automatically apply parameter binding.
• Queries written through the jOOQ DSL are automatically converted to prepared statements, preventing SQL Injection.
• String-based raw SQL must not be used.

// Incorrect example (string concatenation — SQL Injection risk)
dsl.execute("SELECT * FROM users WHERE name = '" + name + "'");

// Correct example (jOOQ DSL — automatic parameter binding)
dsl.selectFrom(USERS)
    .where(USERS.NAME.eq(name))
    .fetch();

---

26.4. Dependency Security

26.4.1. Tool Implementation

• OWASP Dependency-Check must be applied as a Maven plugin. (Refer to the Maven Build Configuration document.)
• The build must fail if vulnerabilities with a CVSS score of 7 or higher are detected.
• Security scans must be executed periodically in the CI pipeline.

26.4.2. Dependency Update Policy

• Dependencies with discovered security vulnerabilities must be updated to a patched version within 7 days.
• Dependency versions must be reviewed regularly (at least once per month).

---

26.5. Secret Management

26.5.1. Prohibitions

• Passwords, API keys, tokens, and other secrets must never be hardcoded in source code.
• If secrets are found in the Git history, they must be revoked immediately and reissued.

26.5.2. Management Methods

Environment	Management Method
Local Development	.env.local file (not tracked by Git)
CI/CD	CircleCI Environment Variables / Context
Production	Environment variables or a secret manager

26.5.3. Secret Exposure Prevention

• .gitignore must include .env.local, *.key, *.pem, and similar files.
• Running a secret scanning tool (e.g., git-secrets, gitleaks) in CI is recommended.