5 easy steps to improve your Spring Boot App’s security

This post is motivated by the fact that more and more services and applications are moving to the internet and are developed exclusively as web applications.
The advantage of this is that the service or application can be used independently of the device type and operating system and only a modern browser is required.
However, there are also many risks involved, since the shift to the Web means that the applications will depend on a large number of open source tools and libraries. This is not a bad thing in principle, but due to the amount used, it can quickly lead to outdated versions or versions with security holes being used.
But this is not the only way security holes can sneak into these applications. Often there are also small unnoticed security critical bugs that the developer overlooks or simply does not know about.

Since the whole topic can lead to endless blog posts, we will limit ourselves here mainly to Spring Boot 2, because it often forms the basis of many web applications and with a few simple tips some security risks can be easily avoided.

First of all, the configurations and vulnerabilities listed here are based on the OWASP TOP 10 list for application security.

In order to know what this list is about, the following is a brief explanation of what it is about.
The OWASP Top 10 is primarily a document that aims to draw attention to the most known vulnerabilities in the web environment. This document has been published annually by the non-profit organization OWASP since 2003.
It is a collection about the most critical security risks for web applications. That list is compiled by security experts from around the world who contribute their knowledge to the project. As this is an internationally recognized collection of security risks and has become a standard for web security, it is used as a reference for this blogpost.

However, we will not cover them all, cause this would be too much for one blog post. Therefore, only 5 vulnerabilities will be covered, which are really easy to avoid.

A1: Injections

Injections are the first point on the OWASP list. In Spring Boot 2 these are mainly SQL injections, but sometimes also OS injections.

SQL injections are mostly created, because the developer is too lazy to use the JPA model and thinks: “Why bother, if it works?”

It might be tempting to write SQL queries by yourself, but require explicit input parameter handling, otherwise they are exposed to some serious weaknesses.

To clarify this an example follows.

This SQL query accepts and executes a string, which can be passed via URL, without any check. Now imagine a potential attacker who uses the following URL to access a Website.

An attacker could now use this to pass

/sqlInjection?name=Rachel;+DROP+TABLE+USER

in addition to the desired parameter. This would cause the SQL-Query

SELECT * FROM USER WHERE name = Rachel ; DROP TABLE USER;

to be executed against the database,which would delete the entire transaction table Users. That could lead to a faulty database and cause irreparable data loss.

To prevent this problem from occurring, it is best to use Spring Boot’s JPA model, which provides the same results in a safe way.

First add the following Code to your CrudRepository.

List<User> findByName(String name);

Next, an endpoint can be implemented that simply calls this method and uses a passed path variable to filter and return the result.

This means that it is no longer possible for a potential attacker to pass his own variable in the URL.

Both endpoints provide the same result, but the second without the possibility to perform an SQL injection.

The second type of injection discussed here is the so-called OS njection.
To avoid OS injections, don’t provide anyone with a method to inject anything on the console, so keep your hands off and everyone is happy.

A2: Broken Authentication

With the second point A2: Broken Authentication, it is also relatively easy to avoid some security problems. To prevent this, a few simple tips are given below.

• Do not transfer sensitive data unencrypted
• No hashes in the markup
• No unnecessary data leaks in the URL

The data leak in the URL occurs more often than you think and at first it doesn’t sound dramatic. But the leaked data could be a session ID for example. Which, in the worst case, could lead to this token being used to take over the identity of a user and use an application in his name.

Accordingly, the developer should always consider what he reveals to the user.

A3: Sensitive Data Exposure

Also, most applications require the user to be provided with some static resources, which brings us to point A3: Sensitive Data Exposure of the list. Examples for resources you want to provide include e.g. CSS files or the favicon. Exposing those is done in Spring Boot 2 using ResourceHandler. This should be configured carefully, otherwise in the worst case it can lead to very sensitive data being released, such as a .htaccess file.

For demonstration purposes, the following is a negative example of how to release all available resource data without restricting it specifically.

A better approach would be exposing just the locations of the necessary files.

A4: External Entity Attack

Another vulnerability that has gained popularity in recent times is the A4: External Entity Attack. This vulnerability is That could lead to a faulty database and cause irreparable data loss. made possible by a POST endpoint that accepts XML. An attacker uses a DTD for a request, in which external entities are loaded. The DTD sent with the request could look like this, for example:

In this case the request would extract the passwd file from the server.

The good news for Spring Boot 2 developers is that by default, there is no way to include DTD with requests and loading external entities is not allowed.

However, there may be cases where this is necessary, and the HTTPMessageConverter simply needs to be extended.

httpMessageConverter.setProcessExternalEntities(true);
httpMessageConverter.setSupportDtd(true) ;

Nevertheless, extreme caution is required and consideration should be given to whether there is another option.

A6: Security Misconfiguration

Now we are at the last weak point, which we will discuss in this blog post
A:6 Security Misconfiguration.

Covering this topic in its entirety would probably fill a blog post of its own, since there are loads of possibilities to misconfigure your security. Multiple config files overriding each other, configuration options changing with version updates, various plugins… and the list does not end there. To configure your security properly means something different for every application out there.

For now, I just want to give you two pieces of advice that are always good to consider:

1. Never perform a delete without checking it
2. the stacktrace should only be for the eyes of the developer and not for everyone. 😉

if you follow those two, you already removed a lot of attack vectors from your application.

Thanks for reading! If you have any questions, suggestions or criticism on this topic, please feel free to contact me.

You might be interested in the other posts published in the Digital Frontiers blog, announced on our Twitter account.