Menu
13 rules for developing secure Java applications

13 rules for developing secure Java applications

How to make Java security a top priority at every stage of application development, from class-level language features to API endpoint authorisation

Credit: Dreamstime

If your organisation is paying for such a license, follow the auto-update route. If not,  you're probably using OpenJDK, and you'll have to do the patching yourself. In this case, you could apply the binary patch, or you could simply replace your existing OpenJDK install with the latest version. Alternatively, you could use a commercially supported OpenJDK like Azul's Zulu Enterprise.

Do you need every security patch?

If you watch the security alerts closely, you may find you don't need a given set of updates. For example, the January 2020 release appears to be a critical Java update; however, a close reading shows that the update only patches holes in Java applet security, and does not affect Java servers.

Java security rule #9: Look for dependency vulnerabilities

There are many tools available to automatically scan your codebase and dependencies for vulnerabilities. All you have to do is use them.

OWASP, the Open Web Application Security Project, is an organization dedicated to improving code security. OWASP's list of trusted, high-quality automated code scanning tools includes several Java-oriented tools.

Check your codebase regularly, but also keep an eye on third-party dependencies. Attackers target both open- and closed-source libraries. Watch for updates to your dependencies, and update your system as new security fixes are released.

Java security rule #10: Monitor and log user activity

Even a simple brute-force attack can be successful if you aren't actively monitoring your application. Use monitoring and logging tools to keep an eye on app health.

If you'd like to be convinced why monitoring is important, just sit and watch TCP packets on your applications listening port. You'll see all kinds of activity, well beyond simple user interactions. Some of that activity will be bots and evil-doers scanning for vulnerabilities.

You should be logging and monitoring for failed login attempts and deploying counter-measures to prevent remote clients from attacking with impunity.

Monitoring can alert you to unexplained spikes, and logging can help unravel what went wrong following an attack. The Java ecosystem includes a wealth of commercial and open source solutions for logging and monitoring.

Java security rule #11: Watch out for Denial of Service (DoS) attacks

Anytime you are processing potentially expensive resources or undertaking potentially expensive operations, you should guard against runaway resource usage.

Oracle maintains a list of potential vectors for this type of problem in its Secure Coding Guidelines for Java SE document, under the "Denial Of Service" heading.

Basically, anytime you go to perform an expensive operation, like unzipping a compressed file, you should monitor for exploding resource usage. Don't trust file manifests. Trust only the actual on-disk or in-memory consumption, monitor it, and guard against bring-the-server-to-its-knees excesses.

Similarly, in some processing it is important to watch for unexpected forever-loops. If a loop is suspect, add a guard that ensures the loop is making progress and short-circuit it if it appears to have gone zombie.

Java security rule #12: Consider using the Java security manager

Java has a security manager that can be used to restrict the resources a running process has access to. It can isolate the program with respect to disk, memory, network, and JVM access. Narrowing down these requirements for your app reduces the footprint of possible harm from an attack. Such isolation can also be inconvenient, which is why SecurityManager isn't enabled by default.

You'll have to decide for yourself whether working around SecurityManager's strong opinions is worth the extra layer of protection for your applications. See the Oracle docs to learn more about the syntax and capabilities of the Java security manager.

Java security rule #13: Consider using an external cloud authentication service

Some applications simply must own their user data; for the rest, a cloud service provider could make sense.

Search around and you'll find a range of cloud authentication providers. The benefit of such a service is that the provider is responsible for securing sensitive user data, not you. On the other hand, adding an authentication service increases the complexity of your enterprise architecture. Some solutions, like FireBase Authentication, include SDKs for integrating across the stack.

Conclusion

I've presented 13 rules for developing more secure Java applications. These rules are tried-and-true, but the greatest rule of all is this: be suspicious. Always approach software development with wariness and a security-minded outlook.

Look for vulnerabilities in your code, take advantage of the Java security APIs and packages, and use third-party tools to monitor and log your code for security issues.

Here are three good high-level resources for staying abreast of the ever-changing Java security landscape:


Tags javaappssoftware

Brand Post

Show Comments