Security: OWASP Top Ten (Notes)

The Open Web Application Security Project (OWASP) provides a top ten security risks in web applications at . The ranking of risks can help developers (and organisations) make their applications more secure.

The 2021 OWASP Top Ten

  • Broken Access Control
  • Cryptographic Failures
  • Injection
  • Insecure Design
  • Security Misconfiguration
  • Vulnerable and Outdated Components
  • Identification and Authentication Failures
  • Software and Data Integrity Failures
  • Security Logging and Monitoring Failures
  • Server Side Request Forgery (SSRF)

Broken Access Control

Access controls should limit the permissions a user has, e.g., stopping user X from accessing confidential data belonging to user Y.

An example of broken access controls includes modifying URLs or APIs, or the HTML of a page. MoonPig faced this issue when customer details were exposed (Thanks to Tom Scott for the excellent YouTube video):

Cryptographic Failures

Using older / weak cryptographic algorithms or sending data in clear text. For example using Hyper Text Transfer Protocol (HTTP) instead of Hyper Text Transfer Protocol Secure (HTTPS) or File Transfer Protocol (FTP) instead of SFTP (Secure File Transfer Protocol).

For example, Outlook could respond as part of the Autodiscovery protocol with a username / password in plain text (although it was Base-64 encoded). The Register ran a story on this at .


Unexpected data sent to a system which may be executed as a command without correct authorisation. Examples include SQL injections and LDAP injections. XKCD has a cool comic strip covering SQL injection:

XKCD 327 – Bobby Tables

Insecure Design

Security should be a key consideration when designing an application. The requirements of the app should include the technical, functional and non-functional. A threat model could be used in the design phase to look at what areas the app writes / reads to or from.

Security Misconfiguration

Security misconfiguration can vary from unnecessary / unneeded features being installed / enabled, e.g. installing Apache web server on a non-web server, or enabling SSH when it is not required, to not disabling / changing default account settings (e.g. default password). To help tackle the issue of default credentials the UK has the Product Security and Telecommunications Infrastructure Bill, which is looking to ban easy-to-guess (non-unique) default passwords. The BBC ran a news story on this at: .

Vulnerable and Outdated Components

Do you know all the versions of the components being used in a web app? Do you know which components have nested dependencies and which versions those dependencies are using? Vulnerabilities can exist in current and outdated components, and it is sometimes years before a vulnerability is known. A list of components and their versions should be kept, and / or a vulnerability scanner should be regularly used to check for vulnerabilities.

Examples of vulnerabilities include the remote code execution (RCE) vulnerabilities found in Apache Log4J 2 at the end of 2021 which Microsoft wrote a threat intelligence guide to at: .

Identification and Authentication Failures

Previously referred to as broken authentication. Identification and authentication failures include permitting automated attacks (e.g., credential stuffing and brute force), default or weak passwords (e.g. admin/admin, P@ssw0rd) and exposing the session identifier within the URL.

Multi-Factor Authentication (MFA) can be used to limit / prevent automated attacks around credential stuff / brute forcing as a secondary key is required alongside the primary key. Implementing tools such as Fail2Ban can also help if multiple incorrect logons or large volumes of abusive traffic occur from an IP address, by blocking that IP address.

Software and Data Integrity Failures

Software is easily available from many websites and repositories, however the software that is being downloaded is not always the software requested. With this in mind software providers offer digital signatures or hash values to increase security. I’ve discussed file hashes before at . Only trusted repositories should be added to operating systems (e.g., the official Ubuntu repos for Ubuntu), otherwise packages being by the installer/updater may be malicious.

Supply chain attacks also fall into this category, including the Solar Winds supply chain attack which Wired covered at: .

Security Logging and Monitoring Failures

Less failures in logging and monitoring solutions, more failures in logging and monitoring solutions that have not been configured correctly. Auditable events (logins, failed logins) should be logged. Warning and errors should generate logs. Logs should not just be stored locally. Logs should be monitored. Consider solutions like an ELK stack (I blogged about ELK at: ), Microsoft Sentinel ( ), Syslog (I blogged about Syslog at: ) and AWS CloudWatch ( ). If you are looking to monitor metrics of a log then Grafana (I blogged about Grafana at: ) may help you.

Logging is important, not only from a security stand point but also from a fault finding point of view. Syslog-Ng make three good points why logging is important at:

Server Side Request Forgery (SSRF)

If a web application is fetching remote resources then there is a chance that an attacker can alter the application requests to request unexpected destinations. A search via DuckDuckGo shows that Google had some SSRF issues. OWASP tackle SSRF at: