Java Security Essentials: A Comprehensive Guide to OWASP Top 10 Vulnerabilities

Konstantin Borimechkov
Tide Engineering Team
9 min readAug 16, 2023

In today’s day and age, where around 4.9 billion people have access to and use the internet, ensuring the security of software applications has never been more critical! Especially if we are looking at applications dealing with PII (Personal Identifiable Information) in the financial, healthcare or other sectors working with such information.

Contents of the article:

  1. How I got introduced to the whole concept of secure coding 🤷‍♂
  2. What is the OWASP Top 10 list 🤔
  3. Listing each component of The OWASP Top 10 list 📝
  4. My personal opinion and experience 🗯
  5. Goodbye notes 👋

My introduction to secure coding 🤷‍♂

I’m currently a software engineer at Tide , the UK’s leading business financial platform, on a mission to save small business owners time (and 💰) on their banking and admin, where security is put above all else and writing the so-called ‘secure code’ is of huge importance.

When I joined the team at Tide in 2022, I was still a junior engineer. Back then the concept of writing secure software wasn’t so familiar to me and I had to dedicate extra time and effort to earn deeper knowledge of the world of internet security. I decided to go trough some learning paths and courses, provided by SecureFlag, where I studied and exercised a lot to improve my secure coding skills and earn some cool certificates in the process.

At the beginning of my journey, I was asked to thoroughly familiarize myself with the OWASP Top 10 (Open Web Application Security Project). These fundamental risks are widely known as the most significant in the world of InfoSec. Here is a brief overview of each one of them⏬

What is The OWASP Top 10 list? 🤔

The Open Web Application Security Project (OWASP) is a non-profit organization founded in 2001, with the goal of helping website owners and security experts protect web applications from cyber attacks.

OWASP has 32,000 volunteers around the world who perform security assessments and research.

The list comprises of the ten most crucial security risks for web applications. Its primary objective is to enhance awareness among developers, security professionals, and organizations regarding security vulnerabilities.

By highlighting these risks, it urges all website and app developers to prioritize addressing these issues and thereby improve the security of their software.

I will be running down the latest OWASP vulnerabilities list, which was released on the 24th of September 2021 (an updated list is compiled and published every 3–4 years), where ‘SQL injection’ has been replaced at the top spot by ‘Broken Access Control’ 👀 .

The OWASP Top 10 List 🔐

1. Broken Access Control

Access control ensures that people can only gain access to things they’re supposed to have access to.

  • This vulnerability arises when an application fails to properly enforce access controls, meaning it allows unauthorized users to access restricted functionalities or data.
  • According to OWASP, 94% of applications were found to have some form of broken access control, with the average incidence rate of 3.81%
  • Here is a video, showcasing an example of broken access control in an insecure bank application.

2. Cryptographic Failures

  • These types of failures are essential for ensuring data confidentiality, integrity & authenticity. There are scores of scenarios, where cryptographic failures can occur. Here are some 👇

❌ Storing personal or sensitive data in an unprotected manner, using no or weak encryption

❌ Not using secure communication protocols such as TLS/SSL

❌ Using weak encryption algorithms to encrypt data

❌ Hardcoding private keys into source code, a.k.a insecure key management

  • Fortunately, as engineers, we can make sure to have minimal to none of these failures occur, if we:

✅ Use encryption standards that we know will hold their own, like Triple DES, AES, the RSA and others.

✅ Use Strong adaptive and salted hashing functions like SHA-256, when saving passwords.

✅ Generally don’t hardcode private information into your source code.

There are a ton more ways to mitigate such failures and I will be covering them in future articles, which you can read and get a notification for, by subscribing to Tide Engineering and following me on Medium! ✌️

3. Injection

✅ Always sanitize the user input, before using it in any business logic and/or DB querying! In that, when coding up a query use parameterized queries or prepared statements!

✅ Separate commands and data to safeguard against injection attacks.

✅ Develop secure APIs that eliminate the risk of any interpreters

4. Insecure Design

  • This is one of the three new categories added to the OWASP list. Insecure design is the lack of security controls being integrated into the application throughout the development cycle.
  • Here is a great video, I found on YouTube, showcasing this security flaw
  • At Tide, we’ve even started doing ‘thread modeling sessions’, where we discuss authentication, access control, business logic, and key flows for each of our services!

5. Security Misconfiguration

  • Gartner estimates up to 95% of cloud breaches stem from human errors. The most common errors here are related to configurations.
  • Security settings and configurations, including but not limited to:

❌ Accepting default settings that are insecure

❌ Overly accessible cloud storage resources

❌ Incomplete configurations

❌ Misconfigured HTTP headers

❌ Verbose error messages that contain sensitive information

… all of these need to be mitigated at all costs. This can be done through:

✅ Continuous monitoring of cloud resources, applications and servers for security misconfigurations.

✅ Changing or removal of default configurations & removing unnecessary default services and features!

✅ Making sure that you write code that’s easy to trace and monitor from the company’s engineers, but limits what the user sees in terms of API request/response information. This includes implementing proper error handling and logging mechanisms to mitigate the showcasing of stack traces in the browser

6. Vulnerable and Outdated Components

  • Although not as popular, this category was ranked first on how often a vulnerability was the root cause of an actual data breach. Using components with known vulnerabilities has caused 24% of the top 50 security breaches in the software space!
  • An example for this is the Ubuntu forums breach in which 2 million usernames, IP addresses and passwords were compromised from the official Ubuntu forums. The cause was a “known SQL injection vulnerability in the Forumrunner add-on which Ubuntu had used and didn’t patch”.
  • The most effective defence 🛡 is continuous scanning of all code components for known vulnerabilities and deploying a patch or other remedy as quickly as possible when a vulnerability is detected. For example, at Tide Engineering we are using Snyk’s product for this!

7. Identification and Authentication Failures

  • Since I bet most of you are familiar with this category, I will just list some vulnerabilities that this category may introduce and give you links to check them out if interested 👇

Brute-Force Attacks; Credential Stuffing

Account Enumeration

Weak Password Policies (please use long passwords and not qwer1234 😅)

Session Management Issues

Insufficient Multi-Factor Authentication for sensitive actions (2FA significantly minimizes the risk of account hacking, since the fact that even if an attack gets your password, he/she still can’t log in to your account 😵)

8. Software and Data Integrity Failures

✅ Use digital signatures to verify the authenticity and integrity of software updates

✅ Triple check your CI/CD pipeline to make sure that it includes adequate segregation, configuration, and access control.

✅ Utilize cryptographic hashes to detect changes in data and ensure its integrity.

9. Security Logging and Monitoring Failures

The Mandiant Security Effectiveness Report 2020 found that 53% of successful cyber attacks infiltrate organizations without being detected, and 91% of all incidents didn’t generate an alert.

❗️The above should ring an alarm for every engineer, who neglects the importance of logging and monitoring.

  • 🤷‍♂️ Not too long ago, I was a victim to this as well. I didn’t think of these two concepts at all and even got angry when more senior engineers told me to fix them up, which meant I had to create a brand new PR and run trough the whole dev cycle. After I read some articles, saw some statistics like the one above and experienced a few bigger BUGs 🐛 and defects, I came to understand that logging and monitoring are of huge importance and should be implemented and thought of just as much as any other code I write.
  • I am very glad that at Tide, we place so much emphasis on this by experimenting with different logging tools like Kibana, DataDog, and ArgoCD. Additionally, having such an arsenal of amazing engineers who are always eager to help and patient in explaining things like proper logging and debugging in a microservices environment!

10. Server-Side Request Forgery

  • Most common cases of this attack include, applications not validating user-inputted URLs, which leads to malicious actors to gain unauthorized access to multiple valuable for the company resources, which may contain PII or other types of secret information. Such resources include but are not limited to:

Internal Services (APIs that are meant to be closed for public use);

Metadata Endpoints (potential access to cloud services metadata endpoints, with which attackers can gain access to private keys and credentials);

Cloud Resources (unauthorized access to storage buckets, databases and etc.);

File Systems (if the app allows for it, attacks could leverage SSRF to access file:// , extracting sensitive files from the server)

.. and all of these are just a few vulnerabilities, which you app may face 😅

  • Preventing the app from suffering a SSRF attacks is to:

✅ Implement input validation

✅ Use whitelisting and/or allow only the access from IPv4 or IPv6 addresses

✅ Validate domain names

✅ Ensure that server-side components have the least privilege required to perform their tasks.

🗯 My Personal Opinion & Experience on the Topic

At the end of the day it’s important for engineers to re-visit ↩ those core security concepts once in a while and especially when the list is officially updated every 3rd to 4th year (meaning, next one should be updated by 2025)! You can check this link to reference the list!

It’s important for companies to also look-after their software and make sure that their engineers have the proper tools in order to stay up-to-date or improve their knowledge in AppSec & InfoSec!

At Tide Engineering, we address all of the above through having engineers focusing solely on security. ‘Security Engineers’ and their respective ‘security’ department are playing a crucial role. In addition, each engineer needs to be familiarised and have up-to-date knowledge on the OWASP vulnerabilities. Every team also goes trough ‘Threat modelling’ sessions in order to showcase that its micro-services are resilient to any security vulnerabilities and can withstand malicious attacks!

We’ve come to the end of this article 🎉

✍️ I hope that this article gave you some quick and simple insights into each of the ten categories, mentioned on the OWASP Top 10!

💻 There is a lot more to impact for each one, but I plan to cover most of them in separate articles, doing more in-depth analysis and with code examples!

💙 Wish you a productive day and secure coding!

--

--

Konstantin Borimechkov
Tide Engineering Team

Writing Code For a Living 🚀 | Software Engineer @ Tide | Writing Blogs About Python & CS