Protecting Your Site from the Most Critical Security Risks

What is the OWASP Top 10? 

The OWASP organization regularly authors a top 10 list, which is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications. 

Here is a list of the top 10 web application security risks from OWASP for the most recently published year, which is 2021. 

• 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)

With each new report, they adjust the categories, rename some, and regroup issues according to what they see on the wild web and what users report.​

It is a good idea to visit the OWASP website to familiarize yourself with the report because they give explanations for each of the changes and also provide additional information, like how many applications were tested in each category. 

Now, let's go into each of these categories from the top 10 list, provide some detail about how it impacts your web application, and then show you how to protect your website or web app from these critical security risks.  

Related Video: 

Broken Access Control 

Broken Access Control is the first security risk identified in the OWASP Top 10, which means out of the applications tested, the security issues present were overwhelmingly due to Broken Access Control.

Access control refers to policies that prevent users from acting outside of their intended permissions.​ 

So the first tip is to make sure to use the roles, permissions, and group features of Sitefinity.​

With Sitefinity, you can easily configure permissions for various parts of the system.​ 

In this screenshot, you have all the various subsystems listed on the left and the groups on the right.  

You can see here that you can alter the FORMS permissions so that the EVERYONE group does not have access to view form data. 

If you are using third-party tools like CRMs, make sure you are checking access control there as well. 

When considering access control, you should also keep in mind the concept of a headless or decoupled system.​ 

Sitefinity has built-in web services making it easy to expose and consume data. 

For example, you might have a mobile application or Single Page Application (SPA) or similar calling APIs to consume that data. 

It is important to configure those APIs or web services to only expose the data you need and to the authenticated users you desire. 

Here you can see how you can configure CORS (Cross-Origin Resource Sharing) to specify which domains can request API data, as well as configure who can access this service. 

Cryptographic Failures

The focus for this category is on failures related to cryptography (or lack thereof), which often lead to exposure of sensitive data. 

Make sure to protect data at rest and at transit.  During transit is usually pretty easy as it is straightforward to disable the older weaker, TLS versions. 

To protect data at rest, encryption can typically be added by the cloud platform. For example, Azure has Transparent Data Encryption that can be turned on for databases to provide a seamless layer of encryption.  Also,  consider end-to-end encryption as data moves between components of your DXP. 

Injection

The next security risk on the OWASP Top10 is Injection.​ 

Injection occurs when systems process invalid data and allow for code or data to be injected into your system.​ 

A first tip here is to not write your own SQL queries, but instead use Sitefinity’s built-in API.​ 

Also, consider using a firewall to monitor injection attempts. 

If possible, you should use a firewall that is configured specifically against the OWASP Top 10.  This screenshot shows the configuration of the Cloudflare firewall with common OWASP rules. You can turn them off and on based on your specific needs. 

Insecure Design

There is a difference between insecure design and insecure implementation. 

A secure design can still have implementation defects leading to vulnerabilities that may be exploited. 

An insecure design cannot be fixed by a perfect implementation as by definition, needed security controls were never created to defend against specific attacks. 

Tips here include:​ 

• Using a partner with secure development practices​
• Use a library of tested components​
• Use an official Sitefinity partner​
• Ask your partner questions about their security practices including policies, code management, etc.​
• As you compose your DXP, look out for data that might flow downstream

For example, this screenshot shows some PII in the history trail for a Zap in the automation tool, Zapier.​ 

Make sure to check logs in your automation tools for data being leaked. 

This category includes Missing security headers as well – like HSTS and Content security policy and cross-site scripting. 

Luckily, Sitefinity has an excellent Web security module baked into the backend.  It is easy to configure these security headers, even if you are not a security expert. 

Here you can see how easy it is to add trusted sources to your content security policy.