When we develop software we don't expect to be hacked or compromised. We build great new software for the needs of our clients. The people that use our software expect that our systems are safe and data will not be compromised. To ensure that safety we need to take responsibility and develop our applications in such a way that we can meet these expectations. Since the situation is real that our application is hacked or compromised. In the guide below, we discuss 7 pointers that can help you develop applications with a minimal security risk.

Securing your application is a very important aspect of the development of your application. You not only need to make sure that the application has the intended functionality but also that this functionality can only be executed by the appropriate people. You not only need to make sure that updates to data are restricted to the correct people, but it is also important that end users only see data they are allowed to see. And in case of sensitive data, this is even more important.

Securing your application is a very important aspect of development. You not only need to make sure that the application has the intended functionality but also that this functionality can only be executed by the appropriate people. It is critical to ensure that updates to data are restricted to the correct people, and that end users only see data they are allowed to see. And in case of sensitive data, this is even more important.

Watch this video to learn how to create a secure web application using multiple Java EE/Jakarta EE APIs and connect it to a MySQL 8 database in this comprehensive tutorial.

Transport Layer Security (TLS) was introduced as a replacement for Secure Sockets Layer (SSL). TLS is a cryptographic protocol which provides secure communication between a client and a server. It also provides a mechanism by which information is not tampered with, falsified or read by anyone other than the intended receiver. TLS 1.3 was released in August 2018 to replace the widely used TLS 1.2. TLS 1.3 comes with stronger cryptographic algorithms and brings in major improvements in performance, security and privacy, which will be discussed in this blog.

This is an updated blog of the original which was published in May 2016

Payara Server provides the Health Check Service for automatic self-monitoring in order to detect future problems as soon as possible. When enabled, the Health Check Service periodically checks some low level metrics. Whenever it detects that a threshold is not met, it triggers alert notifications that allow to detect undesired behavior and predict possible failures. All of these automatic checks are very lightweight and run with a negligible impact on performance.

If your business processes branded credit card data (such as Visa, MasterCard, American Express, and Discover), you must comply with the Payment Card Industry Data Security Standard (PCI DSS). The requirements were developed and are maintained by the Payment Card Industry Security Standards to reduce credit card fraud and implement increased controls around cardholder information. For companies using the Payara Platform, having a Payara Enterprise subscription helps you maintain compliance.

Java EE Security API is one of the new APIs in Java EE 8. With Java EE currently being transferred and rebranded to Jakarta EE, this API will soon be rebranded to Jakarta Security, which is the term we'll use in this article. Jakarta Security is part of the Jakarta APIs, included and active in the Payara Platform by default with no configuration required in order to use it. With some effort, Jakarta Security can be used with Tomcat, as well.  

Java EE 8 introduced a new API called the Java EE Security API (see JSR 375) or "EE Security" in short.

This new API, perhaps unsurprisingly given its name, deals with security in Java EE.  Security in Java EE is obviously not a new thing though, and in various ways it has been part of the platform since its inception.

So what is exactly the difference between EE Security and the existing security facilities in Java EE? In this article we'll take a look at that exact question.

Java SE comes with many security primitives upon which Java EE builds. JAAS for instance is a well known API in this context, from which Java EE uses the Principal, Subject and to some degree the LoginModule types. The Java EE security APIs JACC and JASPIC make direct use of these types.