Site tweaks to improve strict CSP hosting

[rajsite]

Pull Request

🤨 Rationale

The reason for this PR was trying to evaluate Nimble-based apps hosting in Web App hosting under our strict CSP policy. This was done by exercising the nimble site build which covers the following: Angular, Blazor, Vite, Storybook.

In doing so identified some changes that are either useful or minimally invasive as workarounds for WebApp hosting issues or improving the experience of Nimble site if hosted in Web App hosting.

👩‍💻 Implementation

Vite:

• A minimal change to provide a relative base configuration for vite was needed. This causes vite to change from paths relative to root (/script.js) to relative paths in the current directory (./script.js). Reason is WebApps are not hosted in root but from a subdirectory path.

Angular:

• A minimal change to disable inlineCritical styles is needed so that stylesheets included in angular.json load correctly (which seems to be something we figured out and inherited in all apps but doesn't seem to be documented anywhere 🤷 it's like a herd immunity inherited in copy-paste generations 💉). Reason is described in blog / we don't allow unsafe-inline.

Blazor:

• During investigation found that Blazor does not like to serve from index.html urls and relies on path urls. You can actually see it on the current published site if you use a blazor index.html style url instead of a directory url. The page fails to load and has many console errors as Blazor does poor URL parsing / manipulation to load JS resources. It's probably worth creating an issue but I did not yet.
• I thought of a workaround for nimble site by specifying a base url manually of <base href="./" />. This is not compatible with our strict CSP setting and is ignored due to base-uri: 'none';'' (the OWASP strict policy example) causing the errors to continue. We potentially could switch our CSP to base-uri: 'self' but it's not clear to me what the security implications are and I'm not recommending it yet (see following).
• I also found that Blazor seems generally against the idea of serving off index.html vs the directory path as index.html resolution is not supported out of the box in the Router either.
• I thought of a Router workaround for index.html resolution by serving the same component from both the path url and the index.html url. It seems to work but I'm not aware of any other concerns relying on that workaround.
• Even with the above a Blazor 8 app using Nimble will still not run as some Blazor 8 template binding features require using eval and are only addressed in Blazor 9.
• Based on the above, while I'll propose the changes for Nimble's Blazor site page to support index.html based urls working, I'm not going to propose changes to Web App hosting strict CSP base-uri configuration to support the workaround described above. Instead, I think we should say Nimble Blazor WebApp hosting is contingent on Blazor 9 support in Nimble and fixing path serving in Web App hosting. I don't think we should recommend the workarounds I figured out above to Blazor WebApp devs as from the linked issues Blazor does not seem interested in supporting that pattern.

Storybook:

• Depends on unsafe-inline (which we do not allow) and they seem resistant to the change. Need to reply on the issue with a convincing discussion, not sure if MDN and OWASP recommendations are sufficient for them. Did not provide a comment / create an issue.

All:

• Updated links to point to index.html paths as it's minimally invasive (makes the URL bar uglier) but works around AzDo 2941644. This could be reverted in Nimble once the WebApp directory hosting issue is address.
• Updated each page to have a link to the parent page to make them easier to navigate between when hosted in the WebApp hosting iframe.

🧪 Testing

Manual and via built storybook.
Also example hosted on dev:

• Landing (vite)
• Wafer Performance (vite)
• Angular
• Blazor broken, see above
• Storybook expected to be broken, see above (can't explicitly test as deleted from dev package due to size upload bug)

✅ Checklist

• I have updated the project documentation to reflect my changes or determined no changes are needed.