feat: Create nosecone package for adding secure headers to applications #2237
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is my first pass at our
nosecone
package. This implementation is used as middleware and the headers are set for the response.This works really well for Next.js because we can force the headers to be forwarded and it even detects the nonce from the
script-src
directive, which it adds to each<script>
tag that webpack generates. This mechanism doesn't work for Remix or SvelteKit and the nonce is hard to access in Express applications—there are ways to get around this that are framework-specific, but everything will be quite finicky.Notably missing:
My instinct here would be to remove everything except the Next.js middleware support and ship a v0 that we can test in our application and making incremental tweaks.
All that being said, I really don't like the generalized concept here and I think this makes more sense as a series of packages crafted for specific frameworks. For example, SvelteKit would benefit from a split package where the defaults are set in the
svelte.config.js
file and middleware that sets the various other headers, which would defer nonce usage to the framework. We could have these framework-specific packages exist as part of a different monorepo that is managed independently of our SDK.