Must Read for developers: Thirteen rules for developing secure Java applications

The following ground rules offer a good foundation for building more secure Java applications.

Java security rule #1: Write clean, strong Java code

Vulnerabilities love to hide in complexity, so keep your code as simple as possible without sacrificing functionality. Using proven design principles like DRY (don’t repeat yourself) will help you write code that is easier to review for problems.  

Java security rule #2: Avoid serialization

This is another coding tip, but it’s important enough to be a rule of its own. Serialization takes a remote input and transforms it into a fully endowed object.

Java security rule #3: Never expose unencrypted credentials or PII

You must encrypt the password via a one-way cypher before persisting it to the database, and then do it again whenever comparing against that value.

Java security rule #4: Use known and tested libraries

For instance, if you are looking at using JSON Web Tokens to manage authentication and authorization, look at the Java library that encapsulates JWT, and then learn how to integrate that into Spring Security. Even using a reliable tool, it is fairly easy to bungle authorization and authentication. Be sure to move slowly and double check everything you do.

Java security rule #5: Be paranoid about external input

Whether it comes from a user typing into a form, a datastore, or a remote API, never trust external input.

SQL injection and cross-site scripting (XSS) are just the most commonly known attacks that can result from mishandling external input.

Java security rule #6: Always use prepared statements to handle SQL parameters

Anytime you build up an SQL statement, you risk interpolating a fragment of executable code. Knowing this, it’s a good practice to always use the java.sql.PreparedStatement class to create SQL

Java security rule #7: Don’t reveal implementation via error messages

Error messages in production can be a fertile source of information for attackers. Stack traces, especially, can reveal information about the technology you are using and how you’re using it. Avoid revealing stack traces to end users.

Java security rule #8: Keep security releases up to date

As of 2019, Oracle has implemented a new licensing scheme and release schedule for Java. Unfortunately for developers, the new release cadence does not make things easier. Nonetheless, you are responsible for frequently checking for security updates and applying them to your JRE and JDK.

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.

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.

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.

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.

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.

Read more in

https://www.infoworld.com/article/2076837/twelve-rules-for-developing-more-secure-java-code.html

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.