# Content Security Policy script-src unsafe-inline

**URL:** <https://forum.inductiveautomation.com/t/content-security-policy-script-src-unsafe-inline/88056>\
**Category:** Ignition\
**Tags:** ignition81, perspective\
**Created:** [March 28, 2024, 10:28pm UTC](https://forum.inductiveautomation.com/t/content-security-policy-script-src-unsafe-inline/88056 "2024-03-28T22:28:50Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![drojas](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/drojas/32/3403_2.png) [@drojas](https://forum.inductiveautomation.com/u/drojas)\
**Post date:** [March 28, 2024, 10:28pm UTC](https://forum.inductiveautomation.com/t/content-security-policy-script-src-unsafe-inline/88056/1 "2024-03-28T22:28:50Z")

</div>

Calling all Cyber security experts out there. I have our Ignition server behind a WAF and a Reverse Proxy server. The reverse proxy server has the ability to specify Content-Security-Policy headers. In an attempt to obtain a higher/passing score on some cyber security auditing platforms, I added the script-src 'self' directive and now all perspective designer views will not load. They only show a blank screen. If I change the script-src 'unsafe-inline' (which is not recommended), the view loads correctly. I know that the designer uses chromium browser as its page viewer.

So, does anyone know what scripts outside of 'self' the chromium browser calls and where for the page to load?

Update: The Perspective Components panel doesn't populate with items either. But once I add 'unsafe-inline' everything works as it should.

Going down the rabbit hole some more on this.  
There are 2 inline scripts that load on a Perspective page.

the first one is a localStorage.setItem function

```auto
<script>
    localStorage.setItem("redundancy.status", JSON.stringify({
        "activity_level": "Active",
        "role": "Independent",
        "peers": []
    }));
</script>

```

the second one is this.

```auto
        <script>
            window.__qualityCodes = [{
                code: 0,
                name: 'Good_Unspecified'
            }, {
                code: 2,
                name: 'Good_WritePending'
            }, {
                code: 192,
                name: 'Good'
            }, {
                code: 1073742081,
                name: 'Uncertain_LastKnownValue'
            }, {
                code: 1073742082,
                name: 'Uncertain_InitialValue'
            }, {
                code: -2147483136,
                name: 'Bad'
            }, {
                code: -2147483135,
                name: 'Bad_Unauthorized'
            }, {
                code: -1073741056,
                name: 'Error'
           }, {
                code: -1073741044,
                name: 'Error_CycleDetected'
            }];
            window.__assetDigests = {
                "automationstation": "80CAUBEpIEgQ0PELvy76tXdRvKPfWPza4iWnhZQYkmw=",
                "ignition": "OHO486EHIApZN8QQS1pXsqM4Q3aZT/U2R8vu+BxSZMk=",
                "material": "Kp7nlEjvsk96AaSnJDC0YNXTLouKrrJ3wDlxwCaZgZs=",
                "symbol_mimic": "+0NSRQ/D1m+Gs3ynJuceFvqDOAIw0yvfM5fbkneEvCY=",
                "symbol_p&id": "7osguOd5/4WGChLD04YMjQFOxO53jxlUTpiwtb/KK7o=",
                "symbol_simple": "VYS/8nowWa8QK5BgJ0Xl1YFwyJHzKPgveyWFimd3WIc="
            };
            <!-- before render -->
            ReactDOM.render(React.createElement(PerspectiveClient.Client, {
                "projectName": "myProjectName",
                "projectTitle": "myProjectTitle",
                "platformEdition": "standard",
                "coBrandingEnabled": true
            }, null), document.getElementById('app-container'));
        </script>

```

IA Developers...if these 2 scripts had a consistent hash or nonce assigned to them, then we could add that hash/nonce into the CSP header. Otherwise, we have to allow unsafe-inline which it not good practice according to cyber security experts....whomever they are.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [March 29, 2024, 5:02pm UTC](https://forum.inductiveautomation.com/t/content-security-policy-script-src-unsafe-inline/88056/2 "2024-03-29T17:02:28Z")

</div>

I'm not seeing the hazard from those two scripts. I call bovine-[expletive] on that restriction. At least until someone explains.

---

<div class="post-metadata">

**Author:** ![drojas](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/drojas/32/3403_2.png) [@drojas](https://forum.inductiveautomation.com/u/drojas)\
**Post date:** [March 29, 2024, 5:06pm UTC](https://forum.inductiveautomation.com/t/content-security-policy-script-src-unsafe-inline/88056/3 "2024-03-29T17:06:23Z")

</div>

According to some, there shouldn't be any inline scripting. They want all scripts to come from a .js file which presumably would come from your/a trusted server. Because that last part of the script ReactDOM.render never gets called, the page never loads correctly.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [March 29, 2024, 5:08pm UTC](https://forum.inductiveautomation.com/t/content-security-policy-script-src-unsafe-inline/88056/4 "2024-03-29T17:08:49Z")

</div>

> [@drojas](#):
>
> They want all scripts to come from a .js file which presumably would come from your/a trusted server.

But the inline scripts come from that same server. 🤷‍♂️

Ergo, my BS claim.

This seems more like a policy intended to assist deep packet inspection operations, to save parsing workload.

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [March 29, 2024, 5:10pm UTC](https://forum.inductiveautomation.com/t/content-security-policy-script-src-unsafe-inline/88056/5 "2024-03-29T17:10:09Z")

</div>

In this case I think both things are true - it's a silly restriction (since this is still local to the page, and the page itself is what's dynamically generated by the trusted server) _and_ we could "do better" than manually assembling a bunch of strings together in the most primitive way possible on the backend 😆.

---

<div class="post-metadata">

**Author:** ![drojas](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/drojas/32/3403_2.png) [@drojas](https://forum.inductiveautomation.com/u/drojas)\
**Post date:** [March 29, 2024, 5:21pm UTC](https://forum.inductiveautomation.com/t/content-security-policy-script-src-unsafe-inline/88056/6 "2024-03-29T17:21:49Z")

</div>

So we are at a catch-22 here. The perspective site (and designer) works with the lax `"script-src 'self' 'unsafe-inline';` directive...but fails cyber auditing score (which impacts insurance requirements). Maybe the insurance company just wants us to NOT have a web application and yet somehow make money to pay them. Am I in the wrong biz?