.png)
In this blog, we’re tackling a topic that has become essential for every developer: application security. It's complex, but no longer the responsibility of just the experts. After all, every line of code or configuration you write can have a direct impact on an application’s safety.
So how do you tackle security? As a feature that you add at the end of a project? Or is it a mindset that needs to be baked in from the very first line of code? We sat down with Mathias ‘Mathi’ Mariman, one of our managing partners, to discuss the most common dangers, practical tools, and our approach to building software that is secure by design.
Have you heard of the OWASP Top 10? It's a bit like the FBI's Most Wanted list, but for the most important security risks for web applications. You can run into any of them if you're not careful, but Mathi notes that three of them consistently show up in real-world Java and JavaScript projects. Let's take a closer look.
According to Mathi, this is the most common issue. As you know, every application has a whole stack of libraries and frameworks underneath it. And even if you're strict in selecting reputable libraries, they can still cause issues as vulnerabilities are discovered over time.
This happens when a user can access data or perform actions they shouldn't be able to. It's a classic oversight, but it goes deeper than just forgetting to check a user's role. You also have to check for data ownership. Sure, a user might have the 'editor' role, but does that mean they can edit anyone's profile, or just their own?
It’s all about applying the principle of 'least privilege': giving users only the permissions they absolutely need to do their job, and nothing more. A simple mistake here can have major consequences!
Of course, you can't forget about the fundamentals. This covers everything from correctly defining your security mechanisms to properly securing all your endpoints. When setting up a project, developers sometimes intentionally leave a door half-open.
For example, temporarily making an endpoint public to bypass authentication during testing. Convenient when you're testing, but a lot less fun when you forget to fully close that door once you're done and it makes it to production.
So, are there specific pitfalls you should watch out for in Java, JavaScript or other ecosystems? Mathi thinks the risks are mostly universal.
“Any framework can be misconfigured if you’re not careful,” he says. “But a framework like Spring Boot does a good job of giving you a secure starting point. For example, when you add its security library, your endpoints are immediately protected.” Just keep in mind that this basic setup isn’t enough for production. The moment you start customising it, the responsibility is back in your hands!
When it comes to Spring itself, a common oversight is the actuator dependency. It's great for checking the health of your application, but it can expose a lot of internal info by default. These endpoints need to be secured just like any other part of your application, and it’s a step that sometimes gets forgotten. If you don’t, an attacker can get a free map of your system’s potential weak points.
“I always compare it to a refrigerator. You can fill your fridge with fresh products today, and everything is fine. But if you don't check it for a few months, things will go bad. Software dependencies are the same; they have an expiry date, you just don’t know when it is.”
Knowing the risks is one thing, but avoiding them is another. How do we make sure our developers are building secure code from day one? It’s a mix of culture, experience, and good tooling.
“A new developer at Optis learns by doing, surrounded by experienced colleagues in the Optis Factory,” Mathi explains. “Your code gets reviewed by a senior developer who can spot potential issues, and just as importantly, explain the ‘why’ behind the fix.” It's our first line of defence, and we highly recommend you get an extra set of eyes to look at your code as well.
Besides manual code reviews by our experts, we also use a set of automated tools in our CI/CD pipelines to act as a safety net. Consider trying out the following:
But what happens when a major vulnerability, like the one in Apache Log4j a while back, hits the news? “Then the alarm bells go off,” says Mathi. “First, we'll assess the impact and tell our clients what’s going on. Contrary to what people might think, not all vulnerabilities need to be fixed immediately. If it’s high-risk, our experts will take the necessary steps to resolve the issue as quickly as possible.”
If you're trying to set something up quickly, you can't always rely on colleagues and other teams to help you out. Here are Mathi's low-effort, high-impact recommendations to improve your security right now:
If you're trying to protect your applications, the approach is straightforward: don't make security a separate step, but a continuous responsibility, from design to release and beyond.
“A key thing people miss is the difference between badly written code and badly maintained code,” Mathi concludes. “An application with vulnerabilities today might have been perfectly secure when it launched. It’s the lack of maintenance that makes it unsafe. Good security is, fundamentally, good maintenance.”
Security isn't an afterthought; it's a core part of building great software. If you're looking for a partner who shares this mindset, let's talk about your next Java and JavaScript project.
