Security By Design Principles According To OWASP

This blog post focuses on explaining the security by design principles according to The Open Web Application Security Project (OWASP).

The cost of cybercrime continues to increase each year. In a single day, there are about 780,000 data records are lost due to security breaches, 33,000 new phishing messages, and 4,000 ransomware attacks globally.

Analysts expect the total cost of cybercrime to reach $2 trillion in 2019, which is a threefold increase compared to 2015.

Many of the attacks perpetrated by cybercriminals are performed using software vulnerabilities. Software vulnerabilities are often programming mistakes or oversights that leave web applications, web servers, or websites exposed.

It is up to the software programmers to create applications with a high standard of security to prevent these attacks from occurring.

Although securing a website or network resource can be a difficult task, it is made easier thanks to the work done by The Open Web Application Security Project (OWASP).

OWASP provides a comprehensive list of security design principles that programmers should adhere to. Following these principles will ensure that your application is secure and dramatically reduces the risk of a successful cyber attack.

What is OWASP?

OWASP is an online community that produces free tools, documentation, articles, and technologies to help people secure their websites, web applications, and network resources.

It was founded by Mark Curphey, an experienced information security specialist, in 2001. Their primary focus is on web security, application security, and vulnerability assessment.

What are the OWASP Security Design Principles?

The OWASP Security Design Principles have been created to help developers build highly secure web applications.

The OWASP security design principles are as follows:

Asset clarification

Before developing any security strategies, it is essential to identify and classify the data that the application will handle.

OWASP suggests that programmers create security controls that are appropriate for the value of the data being managed. For example, an application processing financial information must have much tighter restrictions than a blog or web forum.

Understanding attackers

Programmers should design controls that prevent misuse of the application by different types of malicious parties, including (from most to least dangerous):

• Disgruntled staff members and programmers
• Drive-by attacks that release viruses or Trojan attacks onto the system
• Motivated cybercriminals
• Criminal organizations with malicious intent
• Script kiddies

The most dangerous type of attacks that developers must safeguard against are from disgruntled staff members and programmers.

That’s because they usually have a high level of access to sensitive systems. Programmers can use OWASP principles techniques to safeguard against these types of attacks.

Core pillars of information security

OWASP recommends that all security controls should be designed with the core pillars of information security in mind:

• Confidentiality – only allow access to data for which the user is permitted
• Integrity – ensure data is not tampered with or altered by unauthorized users
• Availability – ensure systems and data are available to authorized users when they need it

Security architecture

OWASP recommends that every application has application security measures designed to cover all kinds of risks, ranging from typical usage risks (accidental data erasure) to extreme attacks (brute-force attacks, injection attacks, etc.).

They recommend that developers should consider each feature of the application they are designing and ask the following questions:

• Is the process surrounding this feature as safe as possible? In other words, is this a flawed process?
• If I were evil, how would I abuse this feature?
• Is the feature required to be on by default? If so, are there limits or options that could help reduce the risk from this feature?

By “thinking evil” developers can identify the ways that cybercriminals and malicious individuals might seek to attack a web application.

OWASP suggests that developers also follow the STRIDE / DREAD threat risk modeling technique used by many corporations.

STRIDE helps programmers identify threats and DREAD allows programmers to rate threats.

Security principles

These principles are taken from the OWASP Development Guide and comply with the security principles outlined in Michael Howard and David LeBlanc’s book Writing Secure Code.

They include:

1. Minimise attack surface area

Every time a programmer adds a feature to their application, they are increasing the risk of a security vulnerability.

The principle of minimizing attack surface area restricts the functions that users are allowed to access, to reduce potential vulnerabilities.

For example, you might code a search feature into an application. That search feature is potentially vulnerable to file inclusion attacks and SQL injection attacks.

The developer could limit access to the search function, so only registered users could use it — reducing the attack surface and the risk of a successful attack.

2. Establish secure defaults

This principle states that the application must be secure by default. That means a new user must take steps to obtain higher privileges and remove additional security measures (if allowed)

Establishing safe defaults means there should be strong security rules for how user registrations are handled, how often passwords must be updated, how complex passwords should be, and so on.

Application users may be able to turn off some of these features, but they should be set to a high-security level by default.

3. The principle of Least privilege

The Principle of Least Privilege (POLP) states that a user should have the minimum set of privileges required to perform a specific task.

The POLP can be applied to all aspects of a web application, including user rights and resource access. For example, a user who is signed up to a blog application as an “author” should not have administrative privileges that allow them to add or remove users. They should only be allowed to post articles to the application.

4. The principle of Defence in depth

The principle of defense in depth states that multiple security controls that approach risks in different ways are the best option for securing an application.

So, instead of having one security control for user access, you would have multiple layers of validation, additional security auditing tools, and logging tools.

For example, instead of letting a user log in with just a username and password, you would use an IP check, a Captcha system, logging of their login attempts, brute-force detection, and so on.

5. Fail securely

There are many reasons why a web application would fail to process a transaction. Perhaps a database connection failed, or the data inputted from a user was incorrect.

This principle states that applications should fail in a secure way. Failure should not give the user additional privileges, and it should not show the user sensitive information like database queries or logs.

6. Don’t trust services

Many web applications use third-party services for accessing additional functionality or obtaining additional data. This principle states that you should never trust these services from a security perspective.

That means the application should always check the validity of data that third-party services send and not give those services high-level permissions within the app.

7. Separation of duties

Separation of duties can be used to prevent individuals from acting fraudulently. For example, a user of an eCommerce website should not be promoted to also be an administrator as they will be able to alter orders and give themselves products.

The reverse is also true — an administrator should not have the ability to do things that customers do, like order items from the front end of the website.

8. Avoid security by obscurity

This OWASP principle states that security by obscurity should never be relied upon. If your application requires its administration URL to be hidden so it can remain secure, then it is not secure at all.

There should be sufficient security controls in place to keep your application safe without hiding core functionality or source code.

9. Keep security simple

Developers should avoid the use of very sophisticated architecture when developing security controls for their applications. Having mechanisms that are very complex can increase the risk of errors.

10. Fix security issues correctly

If a security issue has been identified in an application, developers should determine the root cause of the problem.

They should then repair it and test the repairs thoroughly. If the application uses design patterns, it is likely that the error may be present in multiple systems. Programmers should be careful to identify all affected systems.

Frequently asked questions about security by design principles