Why developers need to know the Spring Security framework

Mo' money, mo' problems.

Despite some lofty promises, pricey security investments do not necessarily guarantee an application is immune to vulnerabilities. In fact, they may lull developers into a false sense of security.

Such is the case for Java developers working with open source Spring applications, said Laurentiu Spilca, development lead and trainer at Endava and author of Spring Security in Action. In his consulting work, he has noticed the most common culprit of application vulnerabilities was the improper implementation of security frameworks -- regardless of price point.

Here, Spilca draws on his more than six years of experience with the Spring Security framework to discuss why the open source security architecture is a must-know for Java developers and why baking security into the development pipeline is critical.

Editor's note: This transcript has been edited for length and clarity.

What was the impetus for writing your book Spring Security in Action?

Laurentiu Spilca: Spring Security is often implemented incorrectly in applications. After some research on why that might be, I concluded there is lack of documentation out there about how Spring Security should be used. The available references were heavy and hard to read for a beginner. When I say 'beginner,' I don't mean a junior programmer. I'm referring to someone familiar with the Spring applications who doesn't know how to use Spring Security. Because of that lack of knowledge, they could include vulnerabilities during application development. Then, bad actors could manage to hack the application to exploit those vulnerabilities.

Click to learn more about
Spring Security in Action
by Laurentiu Spilca.

My book is for developers who wish to learn Spring Security step by step and to help them properly apply the framework to secure their applications.

In an excerpt of the book on SearchSecurity, you compare application security to home security. Can you explain this further?

Spilca: In that analogy, I argued that securing an application is similar to how you would secure your home. You must make choices about how many security measures you want to take, as well as how much money you're willing to invest. You can choose to hide your key under the rug, for example. While there is some measure of security there -- and at zero cost -- it will not stop somebody from finding the key and entering the home without too much effort.

Any developer implementing an application with Spring should know Spring Security from start to finish.

Alternatively, you could invest in a fancy alarm system to better protect your home. But, if you don't know how to properly use it, your home -- or application in this comparison -- can still be insecure. You may install it incorrectly and mistakenly disarm the window alarm so that only the front door is secured. Just like in application development, it doesn't matter that you invested a lot of money on the latest alarm system -- if it is not installed correctly, someone can break in anyway.

I've seen this happen frequently in projects. There is a false sense that investing more guarantees better security. Like Spring Security, it doesn't matter that the capabilities to ensure secure application development are there if it is implemented incorrectly.

Why should application developers learn how to implement the Spring Security framework?

Spilca: The Spring Security framework is a tool that applies well to open source Spring applications. It is probably the most used, de facto Java framework in development. Any developer implementing an application with Spring should know Spring Security from start to finish. This way, security is taken into consideration upfront in the development phase.

What are the most common authentication and authorization vulnerabilities you see in applications?

Spilca: I tend to see a lot of application security vulnerabilities that have been outlined in the OWASP [Open Web Application Security Project] Top Ten. I also see vulnerabilities that are not on the current OWASP list but have been in the past. For example, a couple of months ago, I saw a cross-site request forgery [CSRF] vulnerability in an application. We found the reason it happened was that the team of developers did not clearly understand how CSRF protection works with Spring Security.

I've also seen session fixation and injection vulnerabilities in projects, for example. I also saw a situation in which crossover resource sharing wasn't applied correctly, which could have been exploited if it was not mitigated.

Why do the same application security vulnerabilities persist?

Spilca: The causes of the vulnerabilities I have seen in the last couple of years seem to be lack of knowledge or security awareness. It's improved from where we were in the past. Now, we have frameworks and principles to limit the frequency of certain vulnerabilities, but the other challenge is to make sure developers know how to apply them correctly. There may be a lack of knowledge sharing -- consider how developers' work changes frequently. Every year, we have junior developers learning how to write software. If we do not teach them well, of course, they will write bad software, and we will continue to see the same application security vulnerabilities.

Consider clean coding, for example. We have clean coding principles and tutorials everywhere, but I still see code written miserably. The generations of developers change, but they still need time to learn and respect the principles, including YAGNI [You Aren't Gonna Need It] and DRY [Don't Repeat Yourself], code smells and antipatterns. This is why we need to not only teach, but continually instill the importance of best practices for developers, security included.

Recently, there has been a push to shift security left in the development lifecycle. Have you seen a switch to DevSecOps in your work?

Spilca: I am looking forward to when we'll have continuous deployment of security applied within the development pipeline. We see plenty of examples of DevSecOps and its benefits during conference presentations. But, unfortunately, I don't think a lot of projects and companies are implementing it yet. The lack of broad acceptance may have to do with how applications were designed. Big, monolithic, modular applications are more difficult to retrofit with a security-focused pipeline. It is not because architects and developers are opposed to it or do not understand how it works. Rather, more often, the reason is because of stakeholders, who mostly consider short-term budgets and short-term wins rather than long term. Of course, implementing a DevSecOps pipeline takes time, and too many developers prefer to see application functionalities instead of things like security.

Laurentiu Spilca

About the author

Laurentiu Spilca is a dedicated development lead and trainer at Endava, where he directs financial market project development in Nordic European countries. In his work as a development consultant, he collaborates with automation testing teams to develop frameworks for web applications Spring, Hibernate, Selenium, Gauge and JAXB. He has over 10 years of experience as a Java developer and technology educator.