SBN

Evaluating client-side web security: questions to ask your vendor

Third-party tools have transformed your online presence – but you need to secure them or it will all be for nothing. Doing that starts with asking your vendor the right questions, says Tala VP of Engineering, Sanjay Sawhney.

questions for vendors smaller

Magecart, cross-site scripts (XSS) and other data theft attacks on third-party code are increasing exponentially. As more enterprises become aware of the need to secure the client-side, it’s important to understand how the different web security solutions work and what they offer. Here are three key questions you should put to your web application security vendor – and why they’re important:

 

1. What privilege level does your defense layer operate at?

This is the number one question you should ask any vendor. Is it in the browser, or does it sit on top of it? This basic question gets straight to the heart of client-side security: just like endpoints, where kernel-level defenses are far stronger than user-space defenses against malware, security that’s operating from within the browser is more secure.

Think about it: any time you’re building a defense, you want to be operating at least one level of privilege higher than the attackers, so you can at the very minimum observe attacker activity. There’s a reason why web pioneers like Google, PayPal and W3C have adopted this browser-native approach to securing powerful web applications: because when you operate at this higher privilege level, you can detect and block attacks before they can do damage in the user’s space.

When it comes to the browser world, anything in the browser is more secure than anything running on top of it. It’s as simple as that.

2. Is it a JavaScript-based solution?

Because if it is, it’s operating at the same privilege level as the attacker. And that’s a security flaw in and of itself. Sometimes this is referred to as a JS-agent or Virtual JS but they all work in the same way, and they all have the same impact on both performance and security: they can become a single point of failure.

Fundamentally, if your security solution is operating at the same privilege level as the attacker, what advantage does it have? For starters, JS-based solutions typically can’t protect against cross-site scripting (XSS). Additionally, JS-based protection libraries are 3rd parties themselves, making them vulnerable to the exact same types of attack they’re supposed to mitigate.

When you let the browser-native security controls and standards do the work, the browser becomes your enforcer, not any code running on top of it. Because your policies are consumed and applied by the browser, they’re not prone to manipulation because the attacker has no control over them. That puts your security at a higher privilege level, making it significantly stronger.

3. If it’s running on top of the browser, is it the first script that loads on every page?

If you’re using JS-based security, it has to be the very first thing that loads onto the page because it has to hook into all the JS APIs that are provided by that page. There are often 200+ APIs and an attack can happen through any one of them; to add to the challenge, those APIs are not the same across the different browsers. To prevent that, the JS-based solution has to hook into all of these, and to be truly comprehensive and secure, it has to do that for all of them.

And here’s another thing: all that hooking impacts performance. You can’t take the same approach to security as you do for user experience, where a sample of users is enough to feed into marketing or other UX tracking etc. When it comes to security, you have to monitor and/or each and every interaction, sampling won’t work. So now, you’re running in synchronous blocking mode – nothing else runs or loads until this hooking is complete, effectively making the process a single point of failure. And that’s before you consider the performance implications: any massive synchronous hooking of JavaScript APIs has a serious impact on the browser’s JIT (just in time) optimizations. To cap it all, as mentioned earlier, the solution itself is providing a hook for this attack. Some solutions don’t do complete hooking at the beginning of the page load, meaning they aren’t secured at all as they open a window of opportunity to attackers.

When you use browser-based standards and controls, there’s no perceptible impact on performance because everything is implemented automatically. Policies that are directly consumed by the browser are part of the native implementation itself, meaning there’s no performance degradation when the page loads.

Tala does web application security differently

Tala’s approach to protecting the modern web is fundamentally different from most other solutions. Like Google, the W3C and other web experts, we believe that that answer to client-side security starts in the browser. Not on it or on the server. Securing web applications and plugging client-side vulnerabilities has to happen where all the action is taking place – giving your defense a higher privilege level than the attacker. It’s that simple: if your solution is operating at the same privilege level as the attackers, what advantage does it have over them?

To find out more about how Tala uniquely protects against client-side attacks like Magecart and XSS without impacting on your website’s performance, check out our solution brief or book your FREE website risk analysis here!

 


*** This is a Security Bloggers Network syndicated blog from Tala Blog authored by Sanjay Sawhney, Co-Founder and VP of Engineering. Read the original post at: https://blog.talasecurity.io/evaluating-client-side-web-security-questions-to-ask-your-vendor