A Java program might reject an invalid email address but still print it in a debug log or error response. It might even leave a copy in a temporary file. Handling data safely means deciding what enters the application, where it goes, how long it stays, and who can see it. In a beginner project, those decisions are much easier to make before storage and logging are scattered through the code.
Start with a small data inventory
List the fields your application receives and produces. A registration form might collect an email address, display name, and password, then generate an account ID and record a login time. Each field has a different purpose: the display name may be public, the email address may be private, and the password must not be recoverable from application storage.
For each field, note why you need it, whether you must store it, who can access it, and when you can delete it. Don't collect a birth date or home address just because a form template includes one. Data you never collect cannot leak from your application.
Validate at the boundary, then keep types meaningful
Treat input from a web form, configuration file, or other service as untrusted. Check it when it enters the program, before business logic depends on it. The useful question is whether a value has the right shape and size for its intended use, not whether it looks harmless in every possible context.
- Length: Set reasonable limits, including for strings that could otherwise use excessive memory or storage.
- Required values: Distinguish a missing field from an empty string, and decide whether either is acceptable.
- Format: Parse dates and numbers with appropriate Java APIs. A string check alone does not guarantee that a later conversion will succeed.
- Allowed values: Use a defined set for fields such as account status instead of accepting arbitrary text.
Once a value is validated, give it a meaningful type. Use LocalDate for a calendar date, for example, rather than passing its raw string through the application. Validation does not replace authorization: even a perfectly formatted account ID must be checked against the current user's permissions.
Use the database interface, not string assembly
When storing user-provided text through JDBC, use a PreparedStatement with parameter placeholders. The SQL might be INSERT INTO users (email, display_name) VALUES (?, ?), followed by setString calls for the values. The driver treats those values as data rather than letting them change the SQL command. Placeholders cannot stand in for table or column names; if an identifier must vary, select it from a fixed allowlist in your code.
Keep database credentials out of source files and repositories. Supply them through a protected configuration mechanism suited to your deployment, limit the database account to the operations the application needs, and close JDBC resources with try-with-resources.
Protect data differently at each destination
A database, a web page, a log, and a network connection each call for different safeguards. A value safely stored with a database parameter is not automatically safe to put in HTML. When rendering user text, use your framework's context-aware escaping for its destination. HTML text, attributes, URLs, and JavaScript have different rules; avoid assembling HTML by concatenating untrusted strings.
Use encrypted connections when transmitting sensitive data to a service or database, and use storage encryption when your system's requirements call for it. Encryption does not replace access controls: an application that can decrypt a field can still expose it through an overly broad endpoint. Passwords need their own approach. Store them with an established, salted, adaptive password-hashing scheme from a maintained library, not reversible encryption or a fast general-purpose digest. Don't implement the hashing scheme yourself.
Keep sensitive values out of logs and errors
Logs should help diagnose failures without becoming another copy of the user database. Don't log passwords, authentication tokens, full payment details, or entire request bodies by default. “Account update failed for request ID 7c31” is usually more useful than a dump of every submitted field. If you include identifiers, consider whether they reveal personal information, and limit log access and retention accordingly.
Java exceptions can include input values in their messages. Record enough detail for an authorized maintainer to investigate, but return a simple error to the user rather than a stack trace or database diagnostic. Test failure paths alongside successful requests: an invalid date or duplicate account may reveal a logging mistake that normal use never triggers.
Limit access and lifetime
Give each part of the application only the data it needs. A profile page may need a display name, not a password hash. A support view may need account status without the full contact record. Enforce these limits on the server; hiding a field in the browser is not access control.
Decide when to remove temporary uploads, exported reports, abandoned registrations, and old logs. Deletion rules depend on the application and its obligations, so document them rather than assuming records should live forever. For tests and screenshots in a learning project, use fabricated accounts instead of real personal details.
A short practice exercise
Build a small Java contact form with a display name and email address. Trace both fields through input, validation, storage, the confirmation page, and logs. Write tests that submit an unusually long name, a missing email address, and HTML-like text in the display name. Check that invalid values are rejected cleanly, storage uses JDBC parameters, the confirmation page displays the text without interpreting it as markup, and no submitted email address appears in the logs. Those checks give you concrete evidence of how the application handles data, including when a request fails.
