Security

Never build SQL by gluing user input into the query text. Use PreparedStatement with ? placeholders (or JPA named parameters) and bind values separately, so input is treated as data, not as code the database runs.

Don't trust the input filename. Resolve the full real path (Path.normalize or File.getCanonicalPath), then check it actually stays inside your intended base directory before opening it. Reject anything that escapes, like ../ sequences.

Bean Validation (annotations like @NotNull, @Size, @Pattern, @Email on fields, triggered by @Valid) checks that incoming data has the expected shape at the edge of your app. It reduces bad/malicious input but does not replace output-side defenses like parameterized SQL or encoding.

Passing a single command string to a shell lets attacker input add extra commands (via ; | && etc.). ProcessBuilder with a list of separate arguments runs the program directly with no shell, so each argument stays one literal value.

Strings in Java are immutable and you can't erase them, so a secret stays in memory until garbage collection happens, exposed in heap dumps. A char[] is mutable, so you can overwrite it with Arrays.fill right after use to shorten the exposure.

To encrypt, init the Cipher in ENCRYPT_MODE with the recipient's public key. To decrypt, init in DECRYPT_MODE with the matching private key. Public key locks, private key unlocks.

You call Cipher.getInstance with a transformation string like "AES/GCM/NoPadding". It has three parts: the algorithm (AES), the mode (how blocks are chained, e.g. GCM or CBC), and the padding (e.g. PKCS5Padding or NoPadding).

Ask KeyGenerator for an algorithm like AES, call init() with the key size (for example 256 bits), then generateKey(). It returns a SecretKey you use to encrypt and decrypt.

Call MessageDigest.getInstance("SHA-256") to get an engine, feed bytes with update(...), then call digest() to get the final hash as a byte[]. digest() finishes the computation and resets the engine for reuse.

Use java.security.SecureRandom to fill a fresh byte array (16 bytes) for each password. Don't use java.util.Random or Math.random - they're predictable. The salt is stored with the hash and doesn't need to be secret, just unique and random.

readObject() rebuilds objects from raw bytes and runs special hook methods (like readObject/readResolve) on each class while doing so. An attacker sends bytes describing other classes already on your classpath, and those hooks run code the attacker chose.

JEP 290 added a built-in filter to Java that runs while reading a serialized stream and decides, class by class, whether each class is allowed before it is created. You configure an allowlist so only expected classes pass; everything else is rejected, blocking most gadget-chain attacks.

Serializable is a marker that says a class can be turned into bytes. transient marks a field to be skipped when serializing (so secrets aren't written). serialVersionUID is a version number used to check that the saved bytes match the current class. None of them, by themselves, makes deserialization safe.

Look-ahead deserialization means checking the name of each class in the stream before that class is actually created, and refusing any class you didn't expect. Before JEP 290 you did this by subclassing ObjectInputStream and overriding resolveClass to validate the class name and throw if it's not allowed.

The best fix is to stop using Java native serialization for untrusted input and switch to a data-only format like JSON or Protocol Buffers parsed into known types. Class filters (JEP 290) and gadget removal are good extra layers, but they only reduce the risk; they don't remove the dangerous code-execution surface.

A Permission is an object that names one capability the code is allowed to use, like reading a file or opening a network connection. A .policy text file lists grant blocks that hand those capabilities to code from a given location.

Sealing a package means every class in that package must come from the same JAR file. You turn it on by adding 'Sealed: true' to the JAR's MANIFEST.MF, for one package or the whole archive.

Signing a JAR attaches a digital signature so you can prove who published it and that nobody changed its files afterward. It gives integrity and authenticity — not secrecy.

JEP 411 (Java 17) deprecated the SecurityManager for removal because its main job — sandboxing browser applets — no longer exists, it was hard to use correctly, and it slowed down the whole JDK. Today you isolate untrusted code with the operating system or containers, and use the Java module system for encapsulation.

A ProtectionDomain groups code from the same source with the permissions granted to it. When code is checked, Java looks at every method on the call stack and only allows the action if every one of them has the permission — the most restrictive caller wins.