When deploying Java applications to production environments, security reinforcement needs to start from five key points: 1. Restrict runtime permissions, use non-privileged users to start services, avoid abuse of root permissions, configure SecurityManager (depending on the situation), restrict file system permissions during containerized deployment, disable Spring Boot debug mode and sensitive endpoints; 2. Update dependency libraries and disable unsafe protocols, regularly scan for third-party dependency vulnerabilities, disable SSLv3 and TLS 1.1 and below, force TLS 1.2, enable HTTPS and forward confidentiality algorithms; 3. Handle logs and error messages with caution, avoid recording sensitive data, return common error codes in a unified manner, and disable stack information exposure; 4. Optimize JVM Parameters and start-stop scripts, disable System.gc(), read sensitive information from environment variables or encrypted configurations, and avoid hard-coded passwords on the command line; 5. Continuously monitor and update configurations to ensure that security measures remain effective with the environment change.

When deploying Java applications to production environments, security reinforcement is an important part that cannot be ignored. Many problems are not because of the vulnerability of the code itself, but because of improper configuration, loose permission management, or risk of dependency on the library. Let’s start from several key points and talk about the safety measures that should be paid attention to in actual operation.

Restrict runtime permissions

Java applications run under relatively loose permissions by default, especially when starting services with root or administrator accounts. The principle of minimum permissions is very important here.

• Run Java processes with non-privileged users and avoid using root directly
• Configure SecurityManager (although it is deprecated in the new version, some scenarios are still valuable)
• For containerized deployments, use read-only file systems or limit mount paths
• If using frameworks such as Spring Boot, make sure that debug mode or sensitive endpoints are not enabled (such as /actuator )

For example, if the /actuator/env interface of Spring Boot is exposed to the external network and is not authenticated, an attacker may obtain sensitive information through it or even trigger remote code execution.

Update dependencies and disable unsafe protocols

Java projects often rely on a large number of third-party libraries that may have known vulnerabilities. In addition, SSL/TLS configurations are often ignored.

• Regularly scan for dependencies, using tools such as OWASP Dependency-Check, Snyk, or Sonatype Nexus
• Upgrade to the latest stable version, especially commonly used libraries such as log4j, Jackson, Apache Commons
• Disable outdated protocols such as SSLv3, TLS 1.0, TLS 1.1, and force TLS 1.2 or higher
• Avoid HTTP plaintext transmission and force HTTPS
• Set up the right encryption suite and prioritize the Forward Secrecy algorithm

If your application is still using JDK 8, remember to patch it in time, especially security updates for Oracle and OpenJDK.

Be careful when handling logs and errors

Log leaks sensitive information is a common but easily overlooked issue. Error pages may also expose stack information, providing clues to attackers.

• Avoid recording sensitive data such as passwords, tokens, and keys in the log
• Use log desensitization mechanisms, such as replacing the credit card number ****
• Do not display detailed exception information on the error page, especially in web applications
• The external interface returns a common error code, rather than a specific error description.

For example: If a REST API error returns something like java.lang.NullPointerException at com.example.service.UserService.getUserById(UserService.java:45) , it is equivalent to telling the attacker what went wrong.

JVM parameters and start-stop script optimization

Many people directly write a shell script to start Java applications when deploying, and fill in any parameters. In fact, there are many things that can be strengthened here.

• Startup parameters plus -Djava.security.manager (depending on the situation) and cooperate with policy file control permissions
• Use -XX: DisableExplicitGC to disable System.gc() to prevent performance jitter
• Do not hardcode account passwords for startup scripts, they should be read from environment variables or encrypted configurations.
• Don't write the keystore password to death on the command line, as it is easy to be seen by the ps viewing process.

For example:

 java -jar \
  -Duser.timezone=GMT 8 \
  -XX: UseG1GC \
  -XX: DisableExplicitGC \
  -Djavax.net.ssl.keyStore=/path/to/keystore.jks \
  -Djavax.net.ssl.keyStorePassword=your_password_here \
  app.jar

Although the above command can run, the keyStorePassword is directly exposed to the command line. Once others use ps aux , they can see it, which is very dangerous.

Basically that's it. Java security reinforcement is not a one-time task, but a process that requires continuous monitoring and updates. Some settings may seem simple, but if not done, they may become attack portals.

The above is the detailed content of Java Security Hardening for Production Environments. For more information, please follow other related articles on the PHP Chinese website!