SaaS has become the de facto standard for most B2B tools and B2C applications. As a result, more and more personal and business-critical data is entrusted to third parties who in turn use various third-party solutions themselves. We have a lot more SaaS in our lives, but what about SaaS security?
The increase in SaaS usage means more ways of having your data exposed via attacks and breaches, as your data now lives in many more places. And data breaches are becoming increasingly common. As per the “cost of data breach 2018” report, a typical data breach costs a company $3.68 million. That is money literally leaking out of your cloud.
The takeaway here is that SaaS security matters, and is something everyone should be concerned about. This is doubly true for SaaS providers who need to protect both themselves and their customers against attacks.
Given all this, we decided to take a look at how secure the top thousand growing SaaS companies are. We did simple security scans and analyzed over 3000 URLs to test for the presence of security best practices and protections against the most common types of attacks. (See Table 1 and Table 2).
One thing that immediately jumped out: only 9% of companies have enabled a content security policy that protects against cross-site scripting and other code injection attacks. Cross-site scripting attacks are well known and consistently ranked as a top ten attack against web applications.
The tests for other common security measures also fell flat.
Basic measures, such as strongly enforcing HTTPS and “public key pins,” which help stop eavesdropping and man in the middle attacks, are enabled for only about 25-26% of the URLs.
Other protections against clickjacking and cross-site scripting are weak too with just under 30% using the proper security measures.
The only result which easily crossed the halfway mark at a very high 83.9% turns out be a negative indicator. A phenomenal 83.9% of URLs expose server information, which can act as a treasure trove for attackers.
These results are scary to say the least.
Here are the detailed results of our analysis:
Table 1 : SaaS URLs and their security measures.
Percentage of SaaS URLs that passed the test
What is this measure about?
Content Security Policy
|Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and code injection attacks. These attacks are used for everything from data theft to site defacement to distribution of malware. (Source : MDN)|
Strict Transport Security
|The HTTP Strict-Transport-Security response header (often abbreviated as HSTS) lets a website tell browsers that it should only be accessed using HTTPS, instead of using HTTP. (Source : MDN)|
|Public Key Pins|
|The HTTP Public-Key-Pins response header associates a specific cryptographic public key with a certain web server to decrease the risk of MITM attacks with forged certificates. (Source : MDN)|
|X-Frame Options||30.23%||The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe> or <object>. Sites can use this to avoid clickjacking attacks. (Source : MDN)|
|X-XSS-Protection||30.23%||The HTTP X-XSS-Protection response header is a feature of most browsers that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks. It’s recommended to set it to “mode=block” if you use it to prevent false positive abuse. (Source : MDN)|
|X Content Type option||25.34%||X-Content-Type-Options response HTTP header is a marker used by the server to indicate that the MIME types advertised in the Content-Type headers should not be changed and be followed. This allows to opt-out of MIME type sniffing. In other words, it is a way to say that the webmasters knew what they were doing. Site security testers usually expect this header to be set. (Source : MDN)|
|Expose Server Information (Negative Test)||83.97%||Exposing server information helps attackers to plan and execute targeted attacks. This is a negative test indicating that only about 16% of the companies are doing the right thing.|
|Set-Cookie: HTTP Only||29.89%||Helps reduce XSS attacks by ensuring that cookies are only available server-side.|
|Set-Cookies : Secure||12.98%||The secure flag is an option that can be set by the application server when sending a new cookie to the user within an HTTP Response. The purpose of the secure flag is to prevent cookies from being observed by unauthorized parties due to the transmission of a the cookie in clear text (Source: OWASP)|
|CDN (Content Delivery Network)||41.1%||CDNs help protect against DDoS attacks.|
|Additional measures like RASPs, WAFs, and/or other security tools||25%||These tools are designed to monitor and protect against multiple well-known attacks.|
Plotting the same test results against domains rather than across URLs gives only slightly better results. (See Table 2)
Table 2 : SaaS companies and their security measures.
|Security Measure||Percentage of SaaS domains that passed the test|
|Content Security Policy||17.1%|
|Strict Transport Security||41.7%|
|Public Key Pins||41.7%|
|X Content Type option||43.1%|
|Expose server information (negative test)||94.8%|
|Set-Cookie: HTTP Only||49.2%|
|Content Delivery Network||67.5%|
|Additional security tools||46%|
This is not a great state of affairs. There’s a common belief that security comes later when it comes to building a SaaS startup, and some of that pernicious attitude is reflected here. So what should one do? Does this mean we should be reconsidering the use of SaaS tools?
No, there’s no need to panic. In spite of the scary results above, cloud and SaaS are generally still better options than going on-prem or building out equivalent tools in house. There are significant benefits around agility, cost-effectiveness, and time saving that don’t disappear due to uncertain security situations. Additionally, there may be legitimate reasons for some of these SaaS companies to not implement a few of the protections tested for above.
The only thing you need to do is to use some caution when choosing a SaaS provider. Make verifying their security part of your evaluation process, and push them to take it seriously. After all, it’s your data at stake. If you make security a priority for you, it will become a priority for them as well.
If you’re a SaaS provider, or want a checklist for analyzing the security of your SaaS providers, we put together a security best practices checklist for SaaS CTOs. It’s a good starting point for taking stock of your security posture and taking steps to improve it. Check it out!