@sun-asterisk/sunlint 1.3.39 → 1.3.41

package/skill-assets/sunlint-code-quality/rules/java/C019-error-log-level.md

@@ -0,0 +1,34 @@
+---
+title: Do Not Use Error Log Level For Non-Critical Issues
+impact: MEDIUM
+impactDescription: prevents log noise and ensures relevant alerts
+tags: logging, best-practice, java
+---
+
+## Do Not Use Error Log Level For Non-Critical Issues
+
+The `ERROR` level should be reserved for issues that require immediate developer attention. For expected failures (like invalid user input), use `WARN` or `INFO`.
+
+**Incorrect (error for everything):**
+
+```java
+if (user == null) {
+    log.error("User not found: {}", id); // Should be WARN or INFO
+}
+```
+
+**Correct (appropriate log levels):**
+
+```java
+if (user == null) {
+    log.warn("Attempt to access non-existent user: {}", id);
+}
+
+try {
+    db.save(data);
+} catch (SQLException e) {
+    log.error("Critical database failure", e); // TRUE ERROR
+}
+```
+
+**Tools:** Manual Review

package/skill-assets/sunlint-code-quality/rules/java/C020-no-unused-imports.md

@@ -0,0 +1,34 @@
+---
+title: Do Not Import Unused Modules
+impact: MEDIUM
+impactDescription: reduces compilation time and avoids namespace pollution
+tags: readability, clean-code, java
+---
+
+## Do Not Import Unused Modules
+
+Unused imports clutter the code and can lead to confusion if multiple classes have the same name in different packages.
+
+**Incorrect (unused imports):**
+
+```java
+import java.util.List;
+import java.util.ArrayList; // UNUSED
+import java.util.stream.Collectors; // UNUSED
+
+public class MyClass {
+    public void run(List<String> list) { ... }
+}
+```
+
+**Correct (clean imports):**
+
+```java
+import java.util.List;
+
+public class MyClass {
+    public void run(List<String> list) { ... }
+}
+```
+
+**Tools:** IntelliJ "Optimize Imports", Checkstyle (UnusedImports), PMD

package/skill-assets/sunlint-code-quality/rules/java/C022-no-unused-variables.md

@@ -0,0 +1,31 @@
+---
+title: Do Not Leave Unused Variables
+impact: MEDIUM
+impactDescription: reduces clutter and potential for logic errors
+tags: readability, clean-code, java
+---
+
+## Do Not Leave Unused Variables
+
+Variables that are declared but never used should be removed to keep the code focused and avoid confusion.
+
+**Incorrect (unused variable):**
+
+```java
+public void process() {
+    int count = 0; // UNUSED
+    String name = "Admin";
+    System.out.println(name);
+}
+```
+
+**Correct (clean code):**
+
+```java
+public void process() {
+    String name = "Admin";
+    System.out.println(name);
+}
+```
+
+**Tools:** IntelliJ Inspections, SonarQube (S1481), SpotBugs

package/skill-assets/sunlint-code-quality/rules/java/C023-no-duplicate-names.md

@@ -0,0 +1,37 @@
+---
+title: No Duplicate Variable Names In Scope
+impact: MEDIUM
+impactDescription: prevents variable shadowing and unintentional logic errors
+tags: clean-code, maintainability, java
+---
+
+## No Duplicate Variable Names In Scope
+
+Using the same name for a local variable as a member variable (shadowing) makes the code hard to read and can lead to bugs where the wrong variable is updated.
+
+**Incorrect (shadowing):**
+
+```java
+public class UserService {
+    private String name;
+
+    public void updateName(String name) {
+        // VULNERABLE: Which 'name' is being used?
+        name = name; // Bug: logic error
+    }
+}
+```
+
+**Correct (clear naming):**
+
+```java
+public class UserService {
+    private String name;
+
+    public void updateName(String newName) {
+        this.name = newName;
+    }
+}
+```
+
+**Tools:** IntelliJ Inspections, Checkstyle (HiddenField), SonarQube (S1117)

package/skill-assets/sunlint-code-quality/rules/java/C024-centralize-constants.md

@@ -0,0 +1,36 @@
+---
+title: Centralize Constants In Config Files
+impact: MEDIUM
+impactDescription: improves maintainability by avoiding "magic strings" and "magic numbers"
+tags: refactoring, clean-code, java
+---
+
+## Centralize Constants In Config Files
+
+Literals (strings, numbers) used multiple times should be defined as constants in a centralized place rather than hardcoded throughout the logic.
+
+**Incorrect (hardcoded literals):**
+
+```java
+public void process() {
+    if ("ADMIN".equals(user.getRole())) { // Magic string
+        // ...
+    }
+}
+```
+
+**Correct (centralized constants):**
+
+```java
+public class AuthConstants {
+    public static final String ROLE_ADMIN = "ADMIN";
+}
+
+public void process() {
+    if (AuthConstants.ROLE_ADMIN.equals(user.getRole())) {
+        // ...
+    }
+}
+```
+
+**Tools:** IntelliJ "Extract Constant", Checkstyle (MagicNumber), SonarQube (S1192)

package/skill-assets/sunlint-code-quality/rules/java/C029-catch-log-root-cause.md

@@ -0,0 +1,42 @@
+---
+title: Catch Blocks Must Log Root Cause
+impact: CRITICAL
+impactDescription: ensures debuggability by preserving full exception context
+tags: error-handling, logging, debugging, java
+---
+
+## Catch Blocks Must Log Root Cause
+
+When catching an exception, you must log the actual exception object (the root cause) along with relevant context. Swallowing exceptions or logging only the message makes it impossible to find the line number or the stack trace of the original error.
+
+**Incorrect (swallowing or incomplete logging):**
+
+```java
+try {
+    processData();
+} catch (Exception e) {
+    // VULNERABLE: No stack trace, no context
+    log.error("An error occurred");
+    
+    // VULNERABLE: Swallowed!
+}
+```
+
+**Correct (logging with context and stack trace):**
+
+```java
+try {
+    processData(userId);
+} catch (IOException e) {
+    // SECURE: Log context + the exception object
+    log.error("Failed to process data for user: {}", userId, e);
+    throw new ServiceException("Database error", e); // Wrap and rethrow
+}
+```
+
+**Checklist:**
+- Always pass the exception object `e` as the last argument to the logger.
+- Include unique identifiers (like `userId`, `orderId`) in the log message.
+- Avoid logging only `e.getMessage()`.
+
+**Tools:** SonarQube (S1166), SpotBugs, Manual Review

package/skill-assets/sunlint-code-quality/rules/java/C030-custom-error-classes.md

@@ -0,0 +1,50 @@
+---
+title: Use Custom Error Classes
+impact: MEDIUM
+impactDescription: enables specific error handling and cleaner code structure
+tags: error-handling, clean-code, exceptions, java
+---
+
+## Use Custom Error Classes
+
+Throwing generic exceptions like `RuntimeException` or `Exception` forces the caller to use "catch-all" blocks, which is dangerous and lacks semantic meaning. Custom exceptions allow for fine-grained error handling.
+
+**Incorrect (generic exceptions):**
+
+```java
+public void process(int amount) {
+    if (amount < 0) {
+        throw new RuntimeException("Invalid amount");
+    }
+}
+```
+
+**Correct (custom exceptions):**
+
+```java
+public class InsufficientFundsException extends RuntimeException {
+    public InsufficientFundsException(String message) {
+        super(message);
+    }
+}
+
+public void process(int amount) {
+    if (amount < 0) {
+        throw new InsufficientFundsException("Amount cannot be negative");
+    }
+}
+
+// Caller can now catch specifically
+try {
+    service.process(-1);
+} catch (InsufficientFundsException e) {
+    // Handle specifically
+}
+```
+
+**Recommendation:**
+- Inherit from `RuntimeException` for unrecoverable errors (unchecked).
+- Inherit from `Exception` for errors that the caller *must* handle (checked).
+- Use descriptive names (e.g., `UserNotFoundException`, `DatabaseConnectionException`).
+
+**Tools:** IntelliJ Inspections, Manual Review

package/skill-assets/sunlint-code-quality/rules/java/C033-separate-data-access.md

@@ -0,0 +1,46 @@
+---
+title: Separate Processing And Data Access Layers
+impact: HIGH
+impactDescription: enforces clean architecture and improves testability
+tags: architecture, clean-code, java
+---
+
+## Separate Processing And Data Access Layers
+
+Business logic should be decoupled from database operations. Repositories should only handle data retrieval/storage, while Services handle the logic.
+
+**Incorrect (mixed concerns):**
+
+```java
+@Service
+public class OrderService {
+    @Autowired private JdbcTemplate jdbc;
+    
+    public void checkout(Cart cart) {
+        // VULNERABLE: SQL logic directly in Service
+        jdbc.update("INSERT INTO orders...");
+        // complex business logic here...
+    }
+}
+```
+
+**Correct (layered architecture):**
+
+```java
+@Service
+public class OrderService {
+    @Autowired private OrderRepository repository;
+    
+    public void checkout(Cart cart) {
+        // Business logic...
+        Order order = new Order(cart);
+        repository.save(order);
+    }
+}
+
+@Repository
+public interface OrderRepository extends JpaRepository<Order, Long> {
+}
+```
+
+**Tools:** ArchUnit, Manual Review

package/skill-assets/sunlint-code-quality/rules/java/C035-error-context-logging.md

@@ -0,0 +1,38 @@
+---
+title: Log All Relevant Context On Errors
+impact: CRITICAL
+impactDescription: enables efficient incident resolution by providing necessary details
+tags: logging, error-handling, java
+---
+
+## Log All Relevant Context On Errors
+
+An error log without context (like IDs or state) is often useless. Always include enough information to reproduce the issue.
+
+**Incorrect (lacking context):**
+
+```java
+try {
+    paymentService.charge(amount);
+} catch (Exception e) {
+    log.error("Payment failed", e); // Which user? Which order?
+}
+```
+
+**Correct (contextual logging):**
+
+```java
+try {
+    paymentService.charge(orderId, amount);
+} catch (Exception e) {
+    log.error("Payment failed for Order: {} (User: {}). Amount: {}", 
+              orderId, userId, amount, e);
+}
+```
+
+**Recommended Data to Log:**
+- Entity IDs (`userId`, `orderId`).
+- Failed values (if not sensitive).
+- Correlation IDs (`traceId`).
+
+**Tools:** SLF4J (MDC - Mapped Diagnostic Context), Sentry

package/skill-assets/sunlint-code-quality/rules/java/C041-no-hardcoded-secrets.md

@@ -0,0 +1,34 @@
+---
+title: No Hardcoded Secrets In Repository
+impact: CRITICAL
+impactDescription: prevents secrets from being exposed in version control history
+tags: secrets, credentials, git, security, java
+---
+
+## No Hardcoded Secrets In Repository
+
+Passwords, API keys, and tokens must never be written directly into the source code. Even if deleted later, they remain in the Git history.
+
+**Incorrect (secrets in code):**
+
+```java
+// DANGEROUS: Secret is visible to anyone with code access
+public String getS3Client() {
+    return "AKIAIOSFODNN7EXAMPLE"; // AWS Key
+}
+```
+
+**Correct (environment variables or config):**
+
+```java
+// SECURE: Value is loaded at runtime
+public String getS3Client() {
+    return System.getenv("AWS_ACCESS_KEY_ID");
+}
+```
+
+**Prevention:**
+- Use `.gitignore` to exclude config files like `application-local.properties`.
+- Use tools like `git-secrets` or `trufflehog` to scan for secrets before committing.
+
+**Tools:** trufflehog, git-secrets, Gitleaks, SonarQube (S2068)

package/skill-assets/sunlint-code-quality/rules/java/C042-boolean-naming.md

@@ -0,0 +1,27 @@
+---
+title: Boolean Names Prefix
+impact: MEDIUM
+impactDescription: improves code readability by making boolean variables sound like questions
+tags: naming, readability, java
+---
+
+## Boolean Names Prefix
+
+Boolean variables and methods should be prefixed with `is`, `has`, `should`, `can`, or `exists` to be instantly recognizable as true/false values.
+
+**Incorrect (missing prefix):**
+
+```java
+boolean valid = true;
+boolean active(User user) { ... }
+```
+
+**Correct (standard boolean naming):**
+
+```java
+boolean isValid = true;
+boolean hasPermission = false;
+boolean isActive(User user) { ... }
+```
+
+**Tools:** IntelliJ Inspections, Checkstyle, Manual Review

package/skill-assets/sunlint-code-quality/rules/java/C052-controller-parsing.md

@@ -0,0 +1,39 @@
+---
+title: Separate Parsing From Controllers
+impact: HIGH
+impactDescription: keeps controllers thin and focuses them on request routing
+tags: architecture, controllers, java
+---
+
+## Separate Parsing From Controllers
+
+Controllers should handle request mapping and delegation. Heavy parsing, transformation, or mapping logic should be moved to specialized Mapper classes or Services.
+
+**Incorrect (bloated controller):**
+
+```java
+@PostMapping("/users")
+public String createUser(@RequestBody String rawJson) {
+    // VULNERABLE: Parsing logic in Controller
+    JSONObject json = new JSONObject(rawJson);
+    User user = new User();
+    user.setName(json.getString("full_name"));
+    // ...
+    service.save(user);
+    return "OK";
+}
+```
+
+**Correct (clean controller):**
+
+```java
+@PostMapping("/users")
+public ResponseEntity<?> createUser(@Valid @RequestBody UserDto dto) {
+    // Controller only delegates
+    User user = userMapper.toEntity(dto);
+    userService.save(user);
+    return ResponseEntity.ok().build();
+}
+```
+
+**Tools:** MapStruct, Jackson (for automatic parsing), Manual Review

package/skill-assets/sunlint-code-quality/rules/java/C060-superclass-logic.md

@@ -0,0 +1,32 @@
+---
+title: Do Not Ignore Superclass Logic
+impact: MEDIUM
+impactDescription: prevents bugs where base class functionality is unintentionally disabled
+tags: clean-code, inheritance, java
+---
+
+## Do Not Ignore Superclass Logic
+
+When overriding a method, you should usually call `super.methodName()` unless you are intentionally and explicitly replacing the base behavior. This ensures that hooks, logging, or state changes in the parent class are preserved.
+
+**Incorrect (ignoring super):**
+
+```java
+@Override
+protected void onLoginSuccess() {
+    // VULNERABLE: Base class might trigger events or metrics!
+    myCustomLogic();
+}
+```
+
+**Correct (calling super):**
+
+```java
+@Override
+protected void onLoginSuccess() {
+    super.onLoginSuccess(); // Preserves base logic
+    myCustomLogic();
+}
+```
+
+**Tools:** IntelliJ Inspections, Manual Review

package/skill-assets/sunlint-code-quality/rules/java/C067-no-hardcoded-config.md

@@ -0,0 +1,31 @@
+---
+title: Do Not Hardcode Configuration Values
+impact: HIGH
+impactDescription: prevents the need for code changes when environment settings change
+tags: configuration, env-vars, java
+---
+
+## Do Not Hardcode Configuration Values
+
+Values that change between environments (URLs, thread counts, timeouts) should be stored in configuration files or environment variables.
+
+**Incorrect (hardcoded config):**
+
+```java
+public void connect() {
+    String url = "https://prod-api.example.com"; // VULNERABLE to env changes
+}
+```
+
+**Correct (configurable values):**
+
+```java
+@Value("${api.url}")
+private String apiUrl;
+
+public void connect() {
+    // Uses the value from application.properties or ENV
+}
+```
+
+**Tools:** Spring Boot `@Value` / `@ConfigurationProperties`, Manual Review

package/skill-assets/sunlint-code-quality/rules/java/S003-open-redirect.md

@@ -0,0 +1,38 @@
+---
+title: URL Redirects Must Be In Allow List
+impact: MEDIUM
+impactDescription: prevents Open Redirect vulnerabilities used in phishing attacks
+tags: redirect, phishing, security, java
+---
+
+## URL Redirects Must Be In Allow List
+
+Accepting arbitrary URLs for redirection allows attackers to use your trusted domain to trick users into visiting malicious sites (Phishing). Always validate destination URLs against an allow-list.
+
+**Incorrect (arbitrary redirect):**
+
+```java
+// VULNERABLE: Attacker input: ?url=http://malicious-site.com
+@GetMapping("/api/redirect")
+public void handleRedirect(@RequestParam String url, HttpServletResponse response) {
+    response.sendRedirect(url);
+}
+```
+
+**Correct (allow-list validation):**
+
+```java
+private static final List<String> ALLOWED_DOMAINS = List.of("sun-asterisk.vn", "partner.com");
+
+@GetMapping("/api/redirect")
+public void handleRedirect(@RequestParam String url, HttpServletResponse response) {
+    URI uri = URI.create(url);
+    if (ALLOWED_DOMAINS.contains(uri.getHost())) {
+        response.sendRedirect(url);
+    } else {
+        throw new SecurityException("Untrusted redirect destination");
+    }
+}
+```
+
+**Tools:** OWASP ZAP, Manual Audit, SonarQube (S5146)

package/skill-assets/sunlint-code-quality/rules/java/S004-no-log-credentials.md

@@ -0,0 +1,36 @@
+---
+title: Do Not Log Credentials Or Tokens
+impact: CRITICAL
+impactDescription: prevents sensitive authentication data from leaking into logs
+tags: logging, credentials, secrets, security, java
+---
+
+## Do Not Log Credentials Or Tokens
+
+Logging passwords, session tokens, or API keys is a major security violation. Logs are often stored with less security than the actual database and can be accessed by many developers or automated log aggregation tools.
+
+**Incorrect (logging sensitive data):**
+
+```java
+@PostMapping("/login")
+public void login(@RequestBody LoginRequest req) {
+    // VULNERABLE: Password written to logs!
+    log.info("Login attempt for user: {} with password: {}", req.getUsername(), req.getPassword());
+}
+```
+
+**Correct (safely logging):**
+
+```java
+@PostMapping("/login")
+public void login(@RequestBody LoginRequest req) {
+    // SECURE: Only log the username or a masked value
+    log.info("Login attempt for user: {}", req.getUsername());
+}
+```
+
+**Masking Strategy:**
+If you must log sensitive objects, use a custom `toString()` method or a library to mask fields:
+`{ "user": "admin", "password": "****" }`
+
+**Tools:** Logback/Log4j2 filters, Manual Review, SonarQube (S2254)

package/skill-assets/sunlint-code-quality/rules/java/S005-server-authorization.md

@@ -0,0 +1,53 @@
+---
+title: Enforce Authorization At Server Side
+impact: CRITICAL
+impactDescription: prevents unauthorized access to sensitive data and functionality
+tags: authorization, security, server-side, access-control, java
+---
+
+## Enforce Authorization At Server Side
+
+Client-side checks (hiding buttons, disabling links) are purely for UI/UX. The final decision on whether a user can perform an action must always happen on the server. Otherwise, an attacker can simply call the API endpoint directly.
+
+**Incorrect (client-side or perimeter only):**
+
+```java
+// VULNERABLE: Assuming anyone hitting this URL is an admin
+@GetMapping("/admin/delete-user")
+public void deleteUser(@RequestParam Long id) {
+    userRepo.deleteById(id);
+}
+```
+
+**Correct (server-side checks):**
+
+```java
+// 1. Using Spring Security Annotations
+@PreAuthorize("hasRole('ADMIN')")
+@PostMapping("/api/users/{id}/delete")
+public ResponseEntity<?> deleteUser(@PathVariable Long id) {
+    userRepo.deleteById(id);
+    return ResponseEntity.ok().build();
+}
+
+// 2. Resource-level authorization (Owning record check)
+@PostMapping("/api/posts/{id}/edit")
+public ResponseEntity<?> editPost(@PathVariable Long id, @RequestBody PostUpdateData data) {
+    Post post = postRepo.findById(id).orElseThrow();
+    
+    // Explicitly check if the current user is the author
+    if (!post.getAuthorId().equals(CurrentContext.getUserId())) {
+        return ResponseEntity.status(403).body("Forbidden");
+    }
+    
+    post.update(data);
+    return ResponseEntity.ok().build();
+}
+```
+
+**Security Best Practices:**
+- Follow the **Principle of Least Privilege**.
+- Default to **Deny All** and explicitly allow access to specific roles/users.
+- Perform authorization checks for every single request, even for subsequent steps in a multi-step process.
+
+**Tools:** Spring Security, Apache Shiro, Manual Audit