Webview

Android WebView is one of those features that feels harmless right up until it becomes your app’s biggest security problem. If you render untrusted HTML, expose Java objects to JavaScript, or load mixed app and remote content into the same WebView, you are building an XSS target. The twist is that XSS in WebView is often worse than browser XSS, because the payload can sometimes reach native app capabilities. That changes the impact from “someone ran JavaScript in a page” to “someone ran JavaScript inside my app.” ...

React Native developers often treat WebView like a harmless rendering box. It’s not. It’s a browser surface with script execution, DOM access, navigation, message passing, and all the old web security problems packed into a mobile app. That matters because teams frequently use WebView for things like: rendering CMS content showing support articles embedding payment or auth flows previewing user-generated HTML injecting app state into a page running custom JavaScript with injectedJavaScript If untrusted data reaches that surface, you can absolutely end up with XSS-like behavior inside your app. The impact is different from a classic browser XSS, but the bug is still real: attacker-controlled JavaScript runs in your app’s web context. ...

VS Code extension authors often assume XSS is “just a web app problem.” That’s a mistake. If your extension uses a webview, custom editor, notebook renderer, or any HTML UI at all, you’re building a mini browser surface inside an editor that developers trust deeply. That trust changes the impact. A sloppy XSS bug in a marketing site is bad. A sloppy XSS bug in a VS Code extension can expose workspace data, abuse extension APIs indirectly, phish secrets, or trick users into running commands. ...