Absolute security is simple– put your PC in a well-guarded vault, and never power it on. But good luck finding a job that would pay you for such advice. Security Engineering (like all engineering) is a story of tradeoffs. Tradeoffs commonly take place across multiple dimensions:

• Security
• Compatibility
• Performance
• Ease-of-use
• Productivity
• Cost

As we’ve seen recently, the ease-of-use/security tradeoff in the HTML5 Full-screen API leads to a major risk of tech scams. On the other end, the ease-of-use/security tradeoff in the OnBeforeUnload API means that legitimate web applications are harder to use because the platform wants to limit the possibility of abuse.

Recently, someone reached out to ask about the recommendations in the Microsoft Security Baselines for Edge. In particular, they were curious about why the baselines don’t mandate the disablement of WebSerial, WebBluetooth, and WebUSB platform APIs, as each of these represents attack surface against devices from the browser.

When an enterprise Security Admin considers whether to disable these APIs via Group Policy, it’s important to consider the full context to decide whether blocking browser APIs will reduce attack surface, or actually increase it.

In this case, these powerful APIs enable browsers to perform tasks that previously required downloading native applications. For example, instead of needing to download some random full-trust native code application to program my kid’s “smart” teddy bear with his name, favorite song, and favorite food:

… I can just go to a website that supports WebUSB, type in the desired information, manually grant the website permission to use WebUSB, and then update the info on the device. The overall attack surface is dramatically reduced by WebUSB, because my task no longer requires running unsandboxed/full-trust code from a teddy bear vendor, who may or may not have good secure development and deployment practices. At worst, I may have to reset my bear, but the browser sandbox means that my PC is not at risk.

Similarly, a few years back, I bought a cheap clock from Alibaba in China. Setting the time on the clock requires configuration via Bluetooth. Instead of downloading some random full-trust program from an overseas vendor I’ve never heard of, I can use a trivial web app that uses Web Bluetooth to program the device.

Again, there’s no dangerous third-party code running on my PC, and no access to any device is granted unless I specifically choose to allow it.

Ultimately, all features represent attack surface. The key question for security engineers (whether platform engineers or security admins) is whether or not a given feature reduces or improves overall security.

My position is that these APIs, on the whole, improve the security posture of an environment to the extent that they are able to displace higher-risk alternatives (native apps).

Security Admins should keep in mind that the security baselines are just that, baselines. If their environment is such that they’ve locked down their PCs such that users cannot run native apps of their choosing, then blocking advanced Web APIs probably will not harm their security posture, although it might harm their users’ productivity.

Admins should further take care to ensure that their use of the baselines maximizes their overall security. We recently encountered a customer who had disabled Basic Authentication over HTTP in Edge as a part of following the security baseline:

However, the customer had hundreds of legacy devices that require Basic authentication and are only accessible over HTTP. The customer configured Edge such that these devices’ IPs would load in Internet Explorer Mode. The customer treated this as a workaround for the Security Baseline, and it worked because they hadn’t also enabled the WinINET policy that blocks Basic-over-HTTP.

Thus, the customer could claim compliance with the Edge security baseline, but their workaround put the organization at far greater overall risk, because IE Mode represents a huge amount of attack surface. Allowing that attack surface to be combined with MiTM-able HTTP networking means that any network-based attacker could easily exploit vulnerabilities in the legacy IE code, outside of the strong Chromium sandbox.

Stay safe out there!

-Eric