AI app builders reach for unsafe-inline because it makes things work without fuss: inline scripts and styles just run, no configuration needed. That convenience is exactly the problem. unsafe-inline switches off one of the main protections a Content Security Policy provides, and inside a mobile WebView that can turn a small content injection into access to the data and bridges your app exposes. So the honest answer is that it is not safe, and an AI-generated app that ships it is carrying a weakness it did not warn you about. Here is what the directive does and how to remove it.
Short answer
No, unsafe-inline is not safe to rely on, especially in a WebView. It tells the browser or WebView to execute inline scripts and styles, which disables the Content Security Policy protection against injected inline code, the core defense against cross-site scripting. Per OWASP's CSP guidance, you should avoid unsafe-inline and instead allow specific inline code with a nonce or hash. AI builders often add it by default to make generated code run without setup, so an AI-built app frequently ships it. In a WebView that loads any remote or user-influenced content, that opens a path to script injection, so the fix is to remove it and use nonces or hashes for the few inline scripts you actually need.
What you should know
- It disables a key CSP defense:
unsafe-inlinelets any inline script or style run. - XSS is the risk: without it blocked, injected inline code executes.
- AI builders default to it: generated code often includes it for convenience.
- WebViews raise the stakes: injected script can reach app data and JS bridges.
- Nonces or hashes replace it: allow only specific inline code, not all of it.
What does unsafe-inline actually do?
It tells the WebView to trust and run inline scripts and styles, the kind written directly in the HTML rather than loaded from a file. A Content Security Policy normally blocks inline execution precisely because that is how cross-site scripting attacks run injected code, so a strong policy refuses inline scripts unless they carry a matching nonce or hash. Adding unsafe-inline removes that refusal, allowing every inline script to execute, including any an attacker manages to inject. So the directive does not add a feature; it removes a safeguard. The reason it shows up so often is that making inline code work is easier than configuring nonces, which is exactly the tradeoff an AI builder optimizes for when it generates something that simply runs.
Why is it riskier in a mobile WebView?
Because a WebView is usually wired into your app, not sandboxed like a random browser tab. The table contrasts the exposure.
| Context | What injected script can reach |
|---|---|
| WebView with a JS bridge | Native functions the bridge exposes to the page |
| WebView holding a session | Tokens or cookies available to the loaded content |
| WebView loading remote content | Anything that content can touch in the app's web context |
| Plain static local HTML, no input | Limited, but still a weakened policy |
In a WebView that exposes native capabilities through a JavaScript bridge or holds a user session, script injected because unsafe-inline is on does not just deface a page, it can call into what the bridge offers or read what the web context holds. The more your WebView is connected to the app, the worse a successful injection becomes, which is why a weakened CSP matters more here than on an isolated web page.
How do you remove unsafe-inline safely?
Replace it with a nonce or hash for the specific inline code you genuinely need, and move the rest into separate script files. A nonce is a random value you put on both the CSP header and the allowed inline script tag for each response, so only your intended script runs; a hash pins the policy to the exact contents of a known inline script. For most apps, the cleaner path is to avoid inline scripts altogether by loading logic from files, which lets your CSP omit inline permission entirely. Pair that with avoiding unsafe-eval, restricting script-src to sources you control, and not loading untrusted remote content into a privileged WebView. The goal is a policy that permits only what you defined, rather than anything inline.
What to watch out for
The first trap is trusting an AI-generated CSP as-is, since builders add unsafe-inline and unsafe-eval by default and label nothing; read the policy your app actually ships. The second is assuming a WebView is safe because it loads your own pages, when remote content, query parameters, or user input can still introduce injected script. The third is leaving a JS bridge broadly exposed to a WebView with a weak CSP, which compounds the risk. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK, AAB, or IPA against OWASP MASVS and checks WebView and network configuration, surfacing a weak Content Security Policy and insecure WebView settings so you can see what your AI-built app shipped before you submit. Tightening the CSP itself is the change you then make in the code.
What to take away
unsafe-inlineis not safe to rely on; it disables the CSP defense against injected inline scripts, the core protection against cross-site scripting.- AI builders often add it by default, so an AI-built app frequently ships it without warning.
- In a WebView with a JS bridge or a session, injected script can reach native functions and app data, making the weakness worse than on an isolated page.
- Remove it, use nonces or hashes for needed inline code, and use a pre-submission scan such as PTKD.com to find a weak CSP in your build.
