The Oracle Java license change has become a hot topic amongst information technology professionals. As of January 2019, administrators who install Java 8 U 202 and later are only able to get security updates when they purchase support for each desktop. Furthermore, Java 11 and above is only available from Oracle under a commercial support agreement. The Java Oracle license change has raised concerns because support costs are expected to rise.

In a previous blog post, we took a look at Java’s custom serialization platform and what the security implications are. And more recently, I wrote about how improvements in Java 17 can help you prevent insecure deserialization. However, nowadays, people aren’t as dependent on Java’s custom serialization, opting instead to use JSON. JSON is the most widespread format for data serialization, it is human readable and not specific to Java.

As a developer, I spend a lot of time in my GitHub account. I write apps, little utilities, and proof of concepts for when I am learning something new. I like to think that, because I spend a lot of time on GitHub, the overall health of my account is pretty high.

In December 2020, I wrote the article Serialization and deserialization in Java: explaining the Java deserialize vulnerability about the problems Java has with its custom serialization implementation. The serialization framework is so deeply embedded inside Java that knowing how dangerous some implementation can be is important. Insecure deserialization can lead to arbitrary code executions if a gadget chain is created from your classpath classes.

If you’ve reached this page, you’re probably familiar with Spring and its basic mechanisms already. From its inception in 2002, Spring has become one of the dominant frameworks to build any kind of web application in Java. Web applications usually are the biggest interface between a company and its users—both internal and external. When security is neglected at the developer level, applications can become very desirable targets to hackers.

This is the ninth entry in blog series on using Java Cryptography securely. We started off by looking at the basics of Java Cryptography Architecture, assembling one crypto primitive after other in posts on Cryptographically Secure Random Number Generator, symmetric & asymmetric encryption/decryption & hashes. In the meantime, we had to catchup with cryptographic update in latest versions of Java. Having looked at some of the most common symmetric cryptography based applications a.k.a.