OWASP - All the buzz in the Cybersecurity world

Being trained at a coding bootcamp to become a Full-Stack Software Developer, I know it’s almost impossible to fit in all the vital information developers need to know, within 15 weeks of content. From front end to back end development, database manipulation, dealing with APIs, styling an app…

hate to break it to you, but Cybersecurity doesn’t play a big part in the curriculum.

I first discovered the world of Cybersecurity through the LLHS (Ladies of London Hacking Society) - shoutout to Eliza May Austin and her incredible team. The very first LLHS event was held at the JustEat HQ in London. As silly as this may sound, I’ve never really taken online security seriously prior to attending this event.

But then again, who really does take Cybersecurity seriously these days apart from people who work in the field?

You say you do?

Do you remember the time you scrolled all the way down to the bottom of a page and ticking off that “I’ve read and accepted the Terms and Conditions” checkbox before you’ve even read it?

Or have you ever illegally downloaded songs or streamed movies online?

Or even sacrificed your personal details in exchange for free public wifi? (It’s ok, promise I won’t tell 🙈)

After attending the LLHS introductory event, I decided to look more into the Cybersecurity world (AKA enter the endless black hole of Google results on it). To my surprise, I discovered that not all hackers looked like this:

To be honest, from my very first Google search on Cybersecurity, I lost interest relatively quickly because the majority of the search results were filled with jargons and (what seemed at the time) extremely complicated concepts that I couldn’t really get a grasp of yet.

Thank the universe for this turning point - I attended a Tech Woman London a few weeks later where the incredibly inspiring Sonya Moisset shared her journey about how she got into the tech industry as well as how big of a role Cybersecurity plays in her career. She also mentioned OWASP. o-what?

Don’t know what this is?

Well, neither did I. So I decided to look into it. Google, YouTube and online sources were my best buds at this point. (Sources used in this article are linked at the end of this blog)

To put in short - the OWASP Foundation is a non-profit organisation that has an extensive online community that enforces good web app security practices. They publish countless amounts of useful guides to help organisations as well as the tech community fight against the dangers and attackers that may cause their web applications to be exploited.

Every few years, the OWASP Foundation publishes and updates the OWASP Top Ten - an overview of the most critical risks that organisations may face.

I’ll be briefly exploring the latest OWASP Top Ten which were published in 2017 and what I’ve learnt so far.

1. Injection

What it is:

When an attacker inputs malicious code through the web app, runs system commands & tricks the backend database to return sensitive data.

How to prevent:

  • Assume that all user input is untrusted data, meaning validation is required before any database commands are run
  • Query Parameterisation instead of free input of database commands
  • Validate user input by putting requirements in place upon field inputs (e.g. alphabetical letters in username input only and all fields must be completed)
  • Limiting the amount of data that is returned per request, in one specific period of time
  • Use of Web App Firewalls (WAF)

2. Broken Authentication

What it is:

When a user is able to enter the web app without using the correct credentials. This can be done through credential stuffing(random input until it works), automated attacks(through known credentials), use of default passwords(such as ‘admin’ or ‘password’) or manipulation of session ids.

How to prevent:

  • Multi-factor Authentication (e.g. adding additional fields such as an authentication token sent via SMS/ email)
  • Password Checking against the top known passwords
  • Setting Password Complexity requirements upon creation/update of user account credentials)
  • Limit amount of failed logins (e.g after 3 failed attempts, the user may be locked out)
  • Server Side Session Management (to create an entirely new session id in the backend so that even if someone has their session open and left the device unsupervised, attackers will not be able to use their session id)

3. Sensitive Data Exposure

What it is:

When sensitive data is leaked/exposed due to using a mix of encrypted and non-encrypted pages in an app (e.g. TLS (Transport Layer Security) and HTTP(HyperText Transfer Protocol)), and weak ciphers which lead to weakly encrypted information.

How to prevent:

  • Classify data by applying controls to the data depending on the level of sensitivity
  • Encrypt data at rest
  • Use strong ciphers when using TLS connection
  • Don’t store sensitive data unless it’s absolutely necessary

4. XML External Entities (XXE)

What it is:

When attackers take advantage of XML parsers/processors on the web app that might parse/process malevolent data. For instance, an XML document may be uploaded onto a web app (e.g. CVs/cover letters on recruitment websites) and may refer to external entities which allow malicious data to attack the victim.

How to prevent:

  • Disable XXE on XML parsers/processors, where possible
  • Disable DTD (Document Type Definition) processing when dealing with untrusted sources of data
  • Use of Source Code Analysis Tools such as SAST(Static App Security Tools) to automate testing of a program’s source code in a ‘non-running state’ from the inside-out, to find faults and fix them before the app is distributed to public/users
  • Use of DAST(Dynamic App Security Tools) to test the application from the outside-in by examining the app in its running state and trying to attack it just like an attacker would
  • Use of Web App Firewalls(WAF)

5. Broken Access Control

What it is:

When certain user groups gain access to other user groups’ functionalities by accident (e.g. when normal users gain admin user rights).

How to prevent:

  • Do a lot of manual tests
  • Deny by default and only give access to users who need it and are allowed to access information
  • Implement access controls once to avoid confusion, then re-use the successfully implemented controls for each user
  • Log failures and alert admin immediately if anomalies occur
  • Limit access so that only known users can access the app
  • Least Privilege Access (only giving minimum access within a limited amount of time to users as per required)

6. Security Misconfiguration

What it is:

When a web app uses a preconfigured server that has known vulnerabilities and errors are accidentally revealed to the user (sometimes disclosing the exact server company details as well as the version), meaning that attackers can find out what the known vulnerabilities are and customise their attack accordingly.

How to prevent:

  • Use of Automated Testing Tools (DAST)
  • Use of Repeatable Processes and ensure that all servers have the same configurations
  • Minimal Platform (only use functionalities that are required - not default ones)
  • Use of Security Derivatives (such as HSTS (HTTP Strict Transport Security), HPKP (HTTP Public Key Pinning), X-Frame Options)
  • Use of Web App Firewalls (WAF)

7. Cross-Site Scripting (XSS)

What it is:

An attacker may inject harmful content via a third party platform (e.g website/email). When the victim opens the website/clicks on the link/downloads a document from the third party platform, their private data may be exposed to the attacker.

Cloudflare has kindly provided a really descriptive diagram on XSS:

(Source: © 2019 Cloudflare, Inc.)

Here’s another example from TechTarget:

(Source: Copyright 2000–2019, TechTarget)

How to prevent:

  • Separate untrusted content from active browser content (e.g. by using a ‘whitelist’ of what is allowed, or using an auto-sanitisation library)
  • Raise awareness to users to avoid downloads of untrusted content/clicks onto unknown links
  • Use of Web App Firewalls (WAF)

8. Insecure Deserialisation

What it is:

An attacker may upload an object (such as a document/image/video) that is serialised onto the byte stream. When the object is deserialised by the victim, ill-natured content can be spread.

How to prevent:

  • Do not accept untrusted user input
  • Make sure all user input is validated and that the sender is verified, before deserialising the object
  • Use of Web App Firewalls (WAF)

9. Using components with known vulnerabilities

What it is:

As a web app is built, developers may be forced to use components with known vulnerabilities. As these vulnerabilities are often publicly published to alert users, attackers may know about them and may exploit them.

How to prevent:

  • Continuous inventory of clients and servers
  • Download components only from trusted sources
  • Have a strategic plan of the web app in order to monitor, patch and configure accordingly
  • Be aware of CVE (Common Vulnerabilities & Exploits)

10. Insufficient Logging and Monitoring

What it is:

This occurs when logging is not effectively implemented throughout an app, meaning that when errors arise, alerts are not raised accordingly. This can lead to issues not being resolved due to lack of awareness or knowledge of what actions to take.

How to prevent:

  • Ensure that there is sufficient content in each log for good understanding of the issue (Not too much/too little content)
  • Use a good log file format (short and clear cut)
  • Implement integrity controls on the log file itself so that if a log is created/edited, it is clear who did it and when
  • Create a solid response plan (by monitoring these logs and having a response plan, there will be no confusion as to what the next steps are in order to combat a certain issue)

And… I think that’s it for now. The OWASP has plenty of practical guides and useful information that I’ll definitely refer to when dealing with integrating good security practices throughout the app development process.

You might think that it will be extremely time-consuming and costly to integrate effective cybersecurity practices, but remember:

It’s always better to be safe than sorry!

If you’ve enjoyed reading this article, please feel free to give me some ‘claps’. As always, I’m still quite new to the Cybersecurity field, so please do leave a comment below to let me know if I’ve made a silly mistake or if you have any feedback for me. Constructive criticism is always welcome ♡

In the meantime, you’ll find me cracking on some Immersive Labs on Cybersecurity as well as digging deeper into the world of OWASP and ethical hacking practices.🐱 💻

(Extremely valuable) sources:

F5 DevCentral


Ladies of London Hacking Society

Tech Women London

With a special thanks to Sonya Moisset and Eliza May Austin for introducing me to the world of Cybersecurity and also providing such valuable mentorship and resources to me. Even though you might not be aware of this, but I’m forever grateful for the opportunities and knowledge you both have given me. Yay to women in tech! 🙌



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store