Certified Application Security Engineer (CASE) - Java Free Sample Questions

Blacklist validation is fundamentally flawed because it is impossible to anticipate all possible malicious inputs. Attackers can use various techniques like case variations ( ), different encodings, or alternative vectors like to bypass simple string replacement. The correct approach is to use a combination of whitelist validation for input and context-aware output encoding.

A structured triage process is crucial for managing SAST findings. It allows the team to systematically review, classify, and suppress non-issues, making the results more relevant and actionable over time.

Focusing on new vulnerabilities (delta scanning) in pull requests makes the feedback immediate and relevant to the developer's current changes. This 'shift-left' approach prevents new technical debt and is less overwhelming than scanning the full codebase on every commit.

False. While using getCanonicalPath() and then validating that the result starts with the expected base directory is a key part of the defense, it is not sufficient on its own. An attacker could still use null byte injection (filename.zip%00.txt) in older versions of Java to bypass checks performed on the filename string after canonicalization. A robust solution requires multiple layers: validating the filename against a strict whitelist of characters, using getCanonicalPath(), and ensuring the resulting path is within the intended storage directory.

Log4j2's property substitution feature allows referencing external sources like environment variables. To prevent accidental logging of a secret, you can provide a default value (e.g., :-[REDACTED]) that will be used if the environment variable is not found. The most robust approach for redaction is using rewrite policies or filters, but based on the provided code snippet, the blank represents the mechanism for substituting properties. The correct syntax would be ${env:API_KEY:-[REDACTED]}. The option describes this mechanism.

In a distributed microservices architecture, using an asymmetric algorithm like RS256 is superior for security. The Auth Service is the single entity that holds the private key and can create (sign) tokens. All other services only need the public key to validate tokens. This adheres to the principle of least privilege, as a compromise of a downstream service (e.g., Product Service) will not lead to a compromise of the signing key. With HS256, every service that validates tokens must also possess the shared secret, increasing the attack surface and the risk of the secret key being leaked, which would allow an attacker to forge valid tokens.

The Java Cryptography Architecture is designed to be extensible through the use of providers. The standard way to add a new provider, like Bouncy Castle, without modifying the JDK installation is to include its JAR in the application's classpath and then call Security.addProvider(new BouncyCastleProvider()) in the application's startup code. This dynamically registers the provider for the current JVM instance, making its algorithms available to the application.

URLs are stored in the browser's history, making the session ID accessible to anyone with access to that history.

Web servers, proxies, and other network appliances often log the full URL of requests, which would include the session ID, potentially exposing it in log files.

Users may unknowingly leak their session by sharing a link from their address bar, allowing others to hijack their session.

The most robust defense against insecure deserialization is to avoid it altogether. Using safe, structured data formats like JSON or XML with a secure parser (e.g., Jackson, GSON) is the recommended practice. These libraries do not execute code during deserialization and are not vulnerable to the gadget chain exploits that affect native Java serialization.

In Spring Boot, the standard and most maintainable way to handle exceptions globally is by creating a class annotated with @ControllerAdvice. Within this class, methods annotated with @ExceptionHandler can catch specific exceptions (or general ones like Exception.class) and define a consistent, safe JSON response structure. This centralizes error handling and prevents sensitive information like stack traces from being leaked to the client.

The jarsigner utility is specifically designed to sign JAR files and verify the signatures of signed JAR files. The build server would use jarsigner with a private key to sign the application JAR. The IoT device would then have the corresponding public certificate and could use jarsigner -verify to confirm both the integrity (the file hasn't been altered) and authenticity (it was signed by the trusted build server) of the JAR before executing it.