Application Security

What is OWASP? Web security standards with the Open Web Application Security Project

06 December 2018 • 2 minutes

Written by Hayden Steel

image for 'What is OWASP? Web security standards with the Open Web Application Security Project'

The Open Web Application Security Project (OWASP) focuses on improving the security of software. OWASP has made a range of tools to help meet web security standards, including automatically identifying security vulnerabilities in web applications.

Forging strong, common sense standards for web development can be challenging due to the massive range of in-use (let alone potential) potential software architectures coupled with rapid advances in technology and practice.

For now, OWASP has emerged as a leading standard for web security.

What is OWASP?

The Open Web Application Security Project (OWASP) is a non-profit organisation focused on improving the security of software.

OWASP has made a range of tools to meet web security standards, including one that automatically finds security vulnerabilities in your web application, and a library that implements a variant of the synchronizer token pattern to mitigate the risk of Cross-Site Request Forgery (CSRF) attacks. They also have documentation for testing guidelines and common attack vectors.

In a nutshell, OWASP helps developers write better, more secure code and gives consumers a better understanding of what’s possible (both in terms of attack and mitigation).

What do the OWASP standards include?

Many common attacks are covered by OWASP standards, which can be broken down into 13 categories:

  1. SQL Injection (SQLi)
  2. Cross Site Scripting (XSS)
  3. Local File Inclusion (LFI)
  4. Remote File Inclusion (RFI)
  5. Remote Code Execution (RCE)
  6. PHP Code Injection
  7. HTTP Protocol Violations
  8. Shellshock
  9. Session Fixation
  10. Scanner Detection
  11. Metadata/Error Leakages
  12. Project Honey Pot Blacklist
  13. GeoIP Country Blocking

Wow! That’s a lot, but what are the top risks?

OWASP’s top 3 security risks for cloud-based applications


Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorisation.

An example of poor security is when an SQL statement, such as…

txtUserId = getRequestString(“UserId”);

txtSQL = “SELECT * FROM Users WHERE UserId = “ + txtUserId;

…can be inserted into an input field intended for comments on a blog.

Broken authentication

Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently.

As the name suggests, the key here is not authorisation, but authentication.

Watch this video for a better understanding AAA security; the difference between authentication, authorisation and accounting.

In a nutshell, the issue is not the application letting the wrong people access resources, but the application letting people assume alternate, more privileged identities, and consequently resource access.

Sensitive data exposure

Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.

Are apps meeting this standards?

Over 80% mobile apps have crypto flaws and 4 of 5 tested web apps fail OWASP security standards. So how do you get it right? Read about the benefits of OWASP here to ensure you adequately set your organisation up for success.


Hayden Steel

Written by Hayden Steel

Full-stack Developer

When Hayden isn’t working on the Codebots platform, he is usually heading to Bunker (our local coffee shop) for his daily brew.