Replies: 20 comments 65 replies
-
|
So apparently using the following config makes it possible to force scripts to not be inlined: This isn't ideal though, bacause assetsInlineLimit (according to vite docs) is also used for images and other resources, not just for scripts. So it would still be nice to have a way to configure this for scripts. |
Beta Was this translation helpful? Give feedback.
-
|
Note that the script and style blocks that Astro inserts in a page for astro islands are not processed by vite, and therefore the above config will not work when you use Astro islands. (See withastro/docs#2150) |
Beta Was this translation helpful? Give feedback.
-
|
OK, I can see a couple of paths that could be explored here, but would need some more expert eyes to evaluate the practicality and additional hurdles these approaches could throw up. Maintain the current inline script behaviourOne possibility might for Astro to provide hashes for the inline island scripts to use in a CSP as suggested by @gerjon-eatch in withastro/docs#2150 and documented in MDN’s Add a hash for the contents of each inline script: Astro could do this automatically:
It would need to know the hash of each inline script on the page and inject each hash into the CSP. Questions
Make it possible to switch off inline scriptsThe other alternative is to hoist inline scripts into one or more external JS modules to avoid the need for managing inline script permissions in the CSP (you can just specify the allowed origin like you do for other hoisted scripts today). This seems superficially simpler, but there may be good reasons why we don’t already do this. |
Beta Was this translation helpful? Give feedback.
-
If there is already a CSP header, the meta tag can only make the policy more restricting. So allowing sources (scripts, styles) by hashes will only work if both the header and the meta tag allow those sources. If only the meta tag contains the hashes, the scripts will not be allowed (unless the header allows them by other means, such as unsafe-inline, or if there is no CSP header).
From an astro user perspective, especially one using SSG, this would imho be the preferred solution. CSP's are commonly managed on proxies, CDN's, or edge servers, or by separate entities within an organisation. In such cases using hashes to whitelist sources is just not practical. |
Beta Was this translation helpful? Give feedback.
-
|
I would love it if something like this could work: ---
// server-side JS if necessary
---
<div id="some-div" />
<script src="@some/npm-module"></script>
<script>
import SomeNpmModule from "@some/npm-module";
SomeNpmModule("#some-div");
</script>This, of course, assumes that |
Beta Was this translation helpful? Give feedback.
-
|
Would using |
Beta Was this translation helpful? Give feedback.
-
|
Sure that would work. The impractical bit would be that you have to get them, and put them in your webserver configuration. And not forget to try and find the changed ones with every astro update you do. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I'm assuming we would output them some how, perhaps to a JSON file. If you use an integration like Is there a problem with having the declaration if you don't wind up using the script? For example, in Astro it is possible to conditionally render a client component. If you don't render it then there will be no script tag. But you won't know that until rendering is complete, so you'll need to always add the header just in case. Is that ok? |
Beta Was this translation helpful? Give feedback.
-
|
Would it be possible for a hypothetical |
Beta Was this translation helpful? Give feedback.
-
For my usecase (which only involves the astro hardcoded inline island scripts) this would be fine. |
Beta Was this translation helpful? Give feedback.
-
Getting all the hashes after the build step would be great, so users can add these to their CD process, right now having to disable the most important CSP directive is imo more than problematic. (and users who don't care about security are not affected at all) |
Beta Was this translation helpful? Give feedback.
-
|
Question is how much time each approach adds to the build time. Bundling everything together would be faster and calculating hashes for everything sounds much slower, I would think. Maybe implement both? Apparently there is vite-plugin-csp. Readme says its still in early development, but maybe there are foundations there. |
Beta Was this translation helpful? Give feedback.
-
|
IMHO unless there's a way to fully turn off / block the use of inline scripts (and inline styles too!) it is effectively impossible to produce a website with AstroJS that meets current-generation security standards. The prevailing word is: https://web.dev/csp/#inline-code-is-considered-harmful From that source:
Mozilla, Google, and others offer security analysis tools e.g. https://observatory.mozilla.org/, Mozilla Laboratory, https://csp-evaluator.withgoogle.com/, etc. and they will only get stricter with their recommendations + scoring over time. I think an ideal DevX would have this controlled via Astro config and if set if the dev even tries to use inline scripts or styles it will produce an error with helpful feedback. Wouldn't Astro be all the more impressive if it didn't only score top marks on performance scores out-of-the-box but security and privacy scores as well? |
Beta Was this translation helpful? Give feedback.
-
|
That link you call the "prevailing word" is 11 years old. A better source would have been https://web.dev/strict-csp/ , which cites this research by Google that flies in the face of "inline code considered harmful".
Browsers are introducing a new |
Beta Was this translation helpful? Give feedback.
-
|
Just wanted to migrate a website that is currently being built with Hugo. Unfortunately this issue is a showstopper for me as I do not want to sacrifice the website's Observatory A+ rating (and the security aspect it's is based on, of course). Setting a CSP HTTP header instead of a meta tag has several advantages. For example:
This (among other reasons) is why HTTP header is the preferred solution (according to W3C: https://www.w3.org/TR/CSP3/#csp-header). For static sites the CSP HTTP header set by the webserver / proxy / CDN can't contain a hash. Hence, I'd suggest to add an option to disable inline scripts / styles and rather include those as externalized resources. Another option for inline scripts/styles with a hash might be added later. But this comes with higher complexity and questionable benefit (hasn't HTTP/2 or /3 taken the fright of multiple/additional page resources?). Would really love to see this changed, soon! BTW: Forget about nonces. W3C says in https://www.w3.org/TR/CSP3/#security-nonces: "Using a nonce to allow inline script or style is less secure than not using a nonce, as nonces override the restrictions in the directive in which they are present.". |
Beta Was this translation helpful? Give feedback.
-
|
Any pointers or examples for a middleware solution for nonces or hashes? |
Beta Was this translation helpful? Give feedback.
-
|
If you use netlify and Astro is set to static, you could use this: netlify-plugin-csp-generator |
Beta Was this translation helpful? Give feedback.
-
|
@Marocco2 unfortunately, I’m not using netlify. Thanks though! |
Beta Was this translation helpful? Give feedback.
-
I believe reading the HTML response defeats the purpose of CSP. If a hacker manages to inject a script into your system and your reading the HTML to determine which hashes to generate then your effectively generating a hash for all scripts, including the hackers. |
Beta Was this translation helpful? Give feedback.
-
Here's a basic one that uses ultrahtml to scan inline attribute styles. Unfortunately, https://github.com/lilnasy/astro-csp-middleware/blob/main/src/middleware.ts |
Beta Was this translation helpful? Give feedback.
-
|
For now I created a tool to parse the |
Beta Was this translation helpful? Give feedback.
-
|
As I learned from this discussions and withastro/astro#7732, inline scripts and styles are part of the design decisions made for Astro and this does not seem to be intended to change. I also understood from #377 (reply in thread) that rendering is streamed and hence the hashes can't be created upfront. Therefore I went the same (only available) route and wrote a small post-processing script to calculate the hashes. For anyone being in the same situation, this might help: Add Meta-CSP placeholder to site layout{
import.meta.env.PROD && (
<meta
http-equiv="Content-Security-Policy"
content="script-src 'self'; style-src 'self'"
/>
)
}Install csp-hashes and dependencypnpm i @localnerve/csp-hashes gulpCreate scriptimport gulp from "gulp";
import hashstream from "@localnerve/csp-hashes";
const distDir = "dist";
gulp
.src(`${distDir}/**/*.html`)
.pipe(
hashstream({
replace: true,
callback: (p, hashes, contents) => {
console.log(hashes.script.all.join(" "));
return contents
.replace(
/script-src 'self'/,
`script-src 'self' ${hashes.script.all.join(" ")}`
)
.replace(
/style-src 'self'/,
`style-src 'self' ${hashes.style.all.join(" ")}`
);
},
})
)
.pipe(gulp.dest(distDir));Update scripts section of package.json "scripts": {
"dev": "astro dev",
"start": "astro dev",
"build": "astro build && pnpm csp",
"preview": "astro preview",
"astro": "astro",
"csp": "node gen-csp.js"
},I'm happy for any suggestions for improvement – especially for getting rid of the large gulp dependency. |
Beta Was this translation helpful? Give feedback.
-
|
I just noticed that the cool new View Transitions feature does not work with this approach. As the transition fetches inline styles from the target page, the Content-Security-Policy header of the source page doesn't match. Consequently Chrome logs something like this:
One way to address this would be to generate the hashes for all inline styles / scripts and add all of them to the CSP header of all html pages. For smaller websites this would work, for larger ones this would result in huge meta tags. |
Beta Was this translation helpful? Give feedback.
-
|
I spent yesterday trying to find a solution to avoid using A few notes about this implementation:
import type { MiddlewareHandler } from 'astro'
import { sequence } from 'astro:middleware'
import cspBuilder from 'content-security-policy-builder'
import { parse } from 'node-html-parser'
import crypto from 'crypto'
const setCspHeader: MiddlewareHandler<any> = async function setCspHeader (_, next) {
const response = await next()
if (response.headers.get('content-type') !== 'text/html') return response
const originalHtml = await response.clone().text()
const parsedHtml = parse(originalHtml)
const newResponse = new Response(parsedHtml.outerHTML, {
status: response.status,
statusText: response.statusText,
headers: response.headers
})
const scripts = parsedHtml.querySelectorAll('script:not([src])')
const scriptHashes = scripts.map(script => createCspHash(script.textContent))
const styles = parsedHtml.querySelectorAll('style')
const styleHashes = styles.map(style => createCspHash(style.textContent))
newResponse.headers.set('Content-Security-Policy', cspBuilder({
directives: {
defaultSrc: ['\'self\''],
scriptSrc: [
'\'self\'',
'https://www.googletagmanager.com',
'https://www.googletagmanager.com',
'https://www.google.com',
'https://www.gstatic.com',
...scriptHashes
],
styleSrc: [
'\'self\'',
'https://fonts.googleapis.com',
...styleHashes
],
fontSrc: [
'https://fonts.gstatic.com'
],
imgSrc: [
'\'self\'',
'https://maps.googleapis.com'
],
frameSrc: [
'https://www.google.com'
],
connectSrc: [
'\'self\'',
'https://www.google-analytics.com'
]
}
}))
return newResponse
}
export const onRequest = sequence(setCspHeader)
function createCspHash (content: string): string {
return `'sha256-${crypto.createHash('sha256').update(content).digest('base64')}'`
}The above middleware produces a CSP similar to this |
Beta Was this translation helpful? Give feedback.
-
|
The more I look at the problem the more I'm convinced that middleware will not be an appropriate solution.
I'm thinking we are going to need something more powerful than parsing the HTML via middleware. Ideally a way to hook into Astro's build system and add a |
Beta Was this translation helpful? Give feedback.
-
|
I don't immediately see how a new API would help CSP + View Transitions. As I understand it, CSP is a way for the initial trusted response to declare trusted sources of code. For view transitions in SPA mode, the very first navigation is the only trusted one. You would need to send every script and style in the first response. Without view transitions (or with view transitions in MPA mode), middleware is a good approach. The one caveat is that you can't stream the response as it generates, you have to buffer it all. I should note this caveat does not make a difference if you're generating a static site. |
Beta Was this translation helpful? Give feedback.
-
|
@lilnasy Okay I'll try to break it down more so we can figure out where we don't understand each other.
The problem is that dynamically generating a hash/nonce for the scripts on the page via middleware defeats the purpose of CSP:
I believe using nonce is going to be the only way to make this work with view transitions. If we could set a nonce value via some Astro API per request and have Astro use that nonce value for the scripts and styles it injects on the page then this would work for both the first navigation and following view transition navigations. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, I understand the problem better now. You bring up a good point, and you are right - it would not be possible to tell apart astro-generated scripts and maliciously injected scripts. I think we could try allowing external scripts and styles where we went with hard-coded inline for performance reasons. I am not sure about nonces because we do not know the count of dynamically generated assets when we create the header. How many is too many? What if it's not enough? Removing uses of dynamically generated assets altogether might be simpler overall. |
Beta Was this translation helpful? Give feedback.
-
|
I took from your ideas and with the help of this article managed to create something that works for me without CSP. remove-inline.cjs const glob = require('tiny-glob');
const path = require('path');
const fs = require('fs');
function hash(value) {
let hash = 5381;
let i = value.length;
while (i) hash = (hash * 33) ^ value.charCodeAt(--i);
return (hash >>> 0).toString(36);
}
async function removeInlineScriptAndStyle(directory) {
console.log('Removing Inline Scripts and Styles');
const scriptRegx = /<script[^>]*>([\s\S]+?)<\/script>/g;
const styleRegx = /<style[^>]*>([\s\S]+?)<\/style>/g;
const files = await glob('**/*.html', {
cwd: directory,
dot: true,
aboslute: true,
filesOnly: true,
});
console.log(`Found ${files.length} files`);
for (const file of files.map((f) => path.join(directory, f))) {
console.log(`Edit file: ${file}`);
let f = fs.readFileSync(file, { encoding: 'utf-8' });
let script;
while ((script = scriptRegx.exec(f))) {
const inlineScriptContent = script[1]
.replace('__sveltekit', 'const __sveltekit')
.replace(
'document.currentScript.parentElement',
'document.body.firstElementChild'
);
const fn = `/script-${hash(inlineScriptContent)}.js`;
f = f.replace(
script[0], // Using script[0] to replace the entire matched script tag
`<script type="module" src="${fn}"></script>`
);
fs.writeFileSync(`${directory}${fn}`, inlineScriptContent);
console.log(`Inline script extracted and saved at: ${directory}${fn}`);
}
let style;
while ((style = styleRegx.exec(f))) {
const inlineStyleContent = style[1];
const fn = `/style-${hash(inlineStyleContent)}.css`;
f = f.replace(
style[0], // Using style[0] to replace the entire matched style tag
`<link rel="stylesheet" href="${fn}" />`
);
fs.writeFileSync(`${directory}${fn}`, inlineStyleContent);
console.log(`Inline style extracted and saved at: ${directory}${fn}`);
}
fs.writeFileSync(file, f);
}
}
removeInlineScriptAndStyle(path.resolve(__dirname, 'dist'));package.json "scripts": {
"dev": "astro dev",
"start": "astro dev",
"build": "astro build && npm run csp",
"preview": "astro preview",
"astro": "astro",
"csp": "node remove-inline.cjs"
},
"dependencies": {
"@astrojs/svelte": "^4.0.2",
"astro": "^3.1.2",
"svelte": "^4.2.1"
},
"devDependencies": {
"tiny-glob": "^0.2.9"
} |
Beta Was this translation helpful? Give feedback.
-
|
I've grabbed this an made it an integration, it is really useful for non-ssr builds import glob from "tiny-glob";
import path from "path";
import fs from "fs/promises";
function hash(value) {
let hash = 5381;
let i = value.length;
while (i) hash = (hash * 33) ^ value.charCodeAt(--i);
return (hash >>> 0).toString(36);
}
export default function extractInlineIntegration() {
return {
name: "astro-extract-inline",
hooks: {
"astro:build:done": async ({ dir }) => {
console.log("Extracting Inline Scripts and Styles");
const scriptRegx = /<script[^>]*>([\s\S]+?)<\/script>/g;
const styleRegx = /<style[^>]*>([\s\S]+?)<\/style>/g;
const normalizedPath = path.normalize(dir.pathname).substring(3);
const files = await glob("**/*.html", {
cwd: normalizedPath,
filesOnly: true,
});
console.log(dir);
console.log(`Found ${files.length} files`);
for (const file of files) {
console.log(`Processing file: ${file}`);
let content = await fs.readFile(path.join(normalizedPath, file), "utf-8");
// Extract and replace inline scripts
content = await extractAndReplace(content, scriptRegx, normalizedPath, "script", "js");
// Extract and replace inline styles
content = await extractAndReplace(content, styleRegx, normalizedPath, "style", "css");
await fs.writeFile(path.join(normalizedPath, file), content);
}
},
},
};
}
async function extractAndReplace(content, regex, directory, prefix, extension) {
let match;
while ((match = regex.exec(content)) !== null) {
const inlineContent = match[1];
const fileName = `/${prefix}-${hash(inlineContent)}.${extension}`;
const filePath = path.join(directory, fileName);
await fs.writeFile(filePath, inlineContent);
console.log(`Inline ${prefix} extracted and saved at: ${filePath}`);
const replacement =
extension === "js" ? `<script type="module" src="${fileName}"></script>` : `<link rel="stylesheet" href="${fileName}" />`;
content = content.replace(match[0], replacement);
}
return content;
} |
Beta Was this translation helpful? Give feedback.
-
|
Adding my 2 cents here, not replying to any specific previous post as it's a mix and match, with replies to multiple people. Starting from the obvious, I'd expect to not have inline styles values when setting
This also mentions the Vite option to remove all inline assets which is, again, not respected. I understand it might be a build phase problem, which I can understand but should be clearly mentioned and if possible worked around, but can also very easily avoided with just a different kind of script tag that also helps to keep a cleaner DOM. Going into solutions proposed, coming on each I saw above. @matthewp mentioned in the issue I opened (withastro/astro#8719), too, that hashes and/or nonces are the ideal option for performance reasons.
Some users above proposed scripts that do it post-build, which is nice, until it doesn't work due to regex parsing, etc. and taking a file that Astro has externally (and links externally in dev builds), bundling into each HTML page, just to then re-split it with possible issues of parsing (like I had in my case) seems counterproductive. Of course |
Beta Was this translation helpful? Give feedback.
-
|
Adding as a comment, but a |
Beta Was this translation helpful? Give feedback.
-
|
I'm also having an issue with this as I'd like to use Astro + Qwik for a chrome web extension, which is very strict about it's inline scripts since manifest v3. The current solution is to run a post build step to undo what Astro does and put the inline scripts in separate external sources. Would love to see this as a config option out of the box, with possible variants such as "no inline", "with nonce" or "with hash". |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Is there any update here? This is a big blocker and the main reason I can't use Astro Islands. It's been more than a year... and 3 new major versions. For the time being the scope of the project still allows for Astro to work, but if I were to need any more feature in which an Island is almost required, I'd have to look elsewhere unfortunately :( |
Beta Was this translation helpful? Give feedback.
-
|
It's not a simple fix unfortunately, it's "rearchitect how islands work and make it work 2 different ways depending on some config" level of complicated. I think it's still something we'd like to do though. |
Beta Was this translation helpful? Give feedback.
-
|
For future reference (and in case people still need help with this): It's very easy to write an Astro integration that outputs the CSP SHA-256 hashes for inlined scripts. One could use the output for their nginx/host provider configuration (for a static website) or even add meta tags in the html pages with appropriate CSP values. This is my implementation import type { AstroIntegration } from 'astro'
import { parse } from 'node-html-parser'
import { readFile } from 'node:fs/promises'
import { fileURLToPath } from 'node:url'
const createCspHash = async (s: string) => {
const hashBuffer = await crypto.subtle.digest('SHA-256', new TextEncoder().encode(s))
const hashBase64 = btoa(String.fromCharCode(...new Uint8Array(hashBuffer)))
return `'sha256-${hashBase64}'`
}
export const astroCSPHashGenerator: AstroIntegration = {
name: 'astro-csp-hash-generator',
hooks: {
'astro:build:done': async ({ dir, pages, logger }) => {
let hashes = ''
for (let i = 0; i < pages.length; i++) {
const filePath = fileURLToPath(`${dir.href}${pages[i].pathname}index.html`)
try {
const root = parse(await readFile(filePath, { encoding: 'utf-8' }))
const scripts = root.querySelectorAll('script')
for (let j = 0; j < scripts.length; j++) {
const hash = await createCspHash(scripts[j].textContent)
hashes += hash + ' '
}
} catch (e) {
logger.error(`Cannot read file ${filePath}: ${e}`)
}
}
logger.info(hashes)
},
},
}This is zero-configuration and only looks at |
Beta Was this translation helpful? Give feedback.
-
|
@PeterDraex I think you're missing the point. This integration is run at build time, so there is no discussion of XSS vulnerability at that point. Using a strong CSP (without unsafe-inline) would eliminate the XSS option |
Beta Was this translation helpful? Give feedback.
-
|
@vanntile oh no, my issue wasn't with you! Your work is great and, in some cases, works wonderfully. This is literally my only issue with Astro right now. It's really annoying and, for the time being, I managed to work around it, but it might not be that easy in all cases to do that. |
Beta Was this translation helpful? Give feedback.
-
|
@vanntile If you don't use any user input during build time then this approach works okay I think. Just thought it's worth pointing out, since people can have different use cases for astro. |
Beta Was this translation helpful? Give feedback.
-
|
@vanntile could you point to code line where the csp header is written to the file itself? I only see how it adds the https://github.com/vanntile/vanntile.com/blob/master/src/lib/utils.ts |
Beta Was this translation helpful? Give feedback.
-
|
@adaptive-shield-matrix As I have mentioned in the description, the above code just outputs the values of all inline scripts' SHA-256 CSP header tags. You can, as mentioned, take the above, MIT licensed code (not that it would matter for such a short snippet) and customize it to suit your needs and to add the output to a meta tag or a static server configuration, at build time. Do feel welcome to do so |
Beta Was this translation helpful? Give feedback.
-
|
I'm deploying my website to Cloudflare and use this very simple middleware to create a nonce and replace all const nonce = crypto.randomUUID();
for (const [header, value] of securityHeader(nonce)) {
response.headers.set(header, value);
}
const html = await response.text();
const result = html
.replaceAll("<script", `<script nonce="${nonce}"`)
.replaceAll("<style", `<style nonce="${nonce}"`);
...As pointed out here #377 (reply in thread) replacing tags like this defeats the purpose of CSP, as persistent XSS scripts would get the nonce assigned and then run on the client. Otherwise this simple setup works surprisingly well, but is not compatible with View Transitions. It would be great if we could get proper nonce support in Astro. |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure nonce is the best path forward, because it has to be regenerated for every request, making it unpractical for static sites. (In my opinion) it would be more useful for everyone to start with hash checks. |
Beta Was this translation helpful? Give feedback.
-
|
Static sites already have a working solution using Only SSR users still rely on the broken middleware approach. |
Beta Was this translation helpful? Give feedback.
-
|
That integration is a very incomplete example with plenty of relevant and uncovered cases. We don't have a good solution yet (I honestly believe that a good solution should not be on "userland", but implemented either inside Astro, or as an official plugin). It also seems that these solutions have some problems when it comes to transitions (I didn't experience it myself because I never worked with transitions). As a side note: I just happened to finish an implementation of my own hook integration and it's arguably quite more complex (by necessity) than that example... If I find some time I might try to package it for others (although I suspect it won't be good enough for the transitions use case either). |
Beta Was this translation helpful? Give feedback.
-
|
In the end I managed to prepare the package: #377 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
I prepared a packaged integration that is able to:
I worked on an Astro integration that adds the integrity hashes to the inlined scripts and styles, and it generates a JS module (in the path of your choice) that exports those hashes, so they can be later used in CSP header configurations or other similar purposes: https://www.npmjs.com/package/@kindspells/astro-sri-csp For now it only does that for the inlined resources, but I'll iterate over it to ensure that it does the same for "external" (both truly external, and served from the origin domain) scripts. |
Beta Was this translation helpful? Give feedback.
-
|
I suspect that it's possible, at least to some extend... although I'm not sure if it's possible to cover all relevant cases (at least right now). We need to access the final state of the generated JS scripts and CSS stylesheets, in case we can't access that data, we have to generate nonce tokens. In case we rely on nonce tokens, then we need a way to pass them to whatever mechanism we used to generate our |
Beta Was this translation helpful? Give feedback.
-
|
@jlarmstrongiv I finally implemented support for SSR https://github.com/KindSpells/astro-shield/releases/tag/1.2.0 , I'm sure it is far from perfect, but might be useful for many people. |
Beta Was this translation helpful? Give feedback.
-
|
That's amazing, a lot of people would find this helpful. A middleware based solution has an inherent vulnerability, though - not all script tags that are printed are trusted. Blanket-allowing all scripts defeats the purpose of the CSP. itmayziii elaborates on it here: #377 (reply in thread). |
Beta Was this translation helpful? Give feedback.
-
|
@lilnasy Yep... in case we have "super dynamic" pages, that risk that you described is not negligible. However... most cases do not fall into that category, they present dynamic content, but don't give any opportunity to external users to inject anything. Having said that, I'll think on what can I do at the integration level to distinguish user-generated script blocks from "legit" script blocks; I'm sure I'll find an acceptable solution. P.S.: As a temporary workaround, inline scripts can be easily disabled by configuring vite to never inline anything (while it is believable that a user could, somehow, inject code... it is much more difficult for attackers to create resources with their own URL in the same origin): export default defineConfig({
vite: {
build: { assetsInlineLimit: 0 },
},
}) |
Beta Was this translation helpful? Give feedback.
-
|
btw, I introduced many limitations on the SSR feature.
|
Beta Was this translation helpful? Give feedback.
-
|
We could easily offer up hashes for the finite number of scripts we need to inline. Matthew brought this up a year ago, but one user expressed hesitation was that it may be infeasible for some people. However, no one specifically said that it would be infeasible for them specifically. I think this is worth bringing up again, because we shouldn't let perfect be the enemy of good enough. In the absence of a proper solution, I am noticing flimsy hacks gain more and more popularity. So, would it be acceptable if astro exported the hashes for the handful of scripts that it may inline? You could create a meta tag, or the header yourself using these. To emphasize, please answer for yourself, your clients, or your organization - not for hypothetical use-cases that other people may have. |
Beta Was this translation helpful? Give feedback.
-
|
Then I love the idea. The only question is if it's not too difficult to implement. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, it would be easy to implement. I want to see how well this matches with the requirements of a few users before I propose this more officially. |
Beta Was this translation helpful? Give feedback.
-
|
This seems like the right approach to me. Astro could expose multiple options for what to do with the hashes it generates in order to support different people's use cases. In my use case (a fully static site), I'd like Astro to...
|
Beta Was this translation helpful? Give feedback.
-
|
Ideally, Astro would note which script tags are present in my source files and only generate hashes for those scripts to avoid allowing any scripts which could be provided by a compromised piece of content. |
Beta Was this translation helpful? Give feedback.
-
|
Ideally they would be available in the source code itself as some exposed context variable, so that one can use them in generating headers files. Cloudflare Pages, Netlify, etc. use As far as I can tell there are only JS scripts that would be inlined in all cases, CSS is removable from the final page pretty easily. |
Beta Was this translation helpful? Give feedback.
-
|
We have to solve this critical issue and get it over with , I think this is the most demanded Astro feature (not feature, rather fix to a critical security vulnerability). This will hold back enterprises and security-valuing individuals from using and adpoting Astro. I think the easiest way for now is to implement Next.js's solution, which is adding a nonce with Middleware. This is the code from their docs: Is this already achievable in Astro? Does Astro have response.headers.set()? P.S. |
Beta Was this translation helpful? Give feedback.
-
|
Nonces are very far from ideal. But adding them inside a middleware layer poses too many risks. For example, if someone managed to inject code into the response of a dynamic page, the middleware would have a difficult time to know if the script/style is legit or not (adding always the nonce without checking that is a huge security problem). This couldd be prevented if the trusted parts of the framework always injected some sort of secret random attribute that the middleware can use to distinguish legit from injected... (this adds extra complexity, a performance penalty, and of course it also requires a final step that removes that secret internal annotation before serving it to the remote client). P.S.: I am the maintainer of https://astro-shield.kindspells.dev , which solves a big chunk of the problem, but it's still very far from being a super-professional solution. |
Beta Was this translation helpful? Give feedback.
-
|
@castarco so what's the ideal solution? To csp in general |
Beta Was this translation helpful? Give feedback.
-
@castarco I think this problem could be circumvented by adopting a solution similar to next.js https://nextjs.org/docs/app/building-your-application/configuring/content-security-policy#adding-a-nonce-with-middleware. Instead of adding nonces to all script/style tags, the middleware only generates the nonce and adds it to the response header. It could also be added to Nonce based CSP in this way is obviously only possible for SSR and not SSG. For SSG a hash based approach definitely makes more sense. |
Beta Was this translation helpful? Give feedback.
-
|
Is there any update on this topic, not visible here? |
Beta Was this translation helpful? Give feedback.
and others
-
When creating astro components/layouts with client side scripts, as documented here: https://docs.astro.build/en/core-concepts/astro-components/, the processed+bundled scripts are rendered inline in the html of the page, during a production build.
This forces the use of a CSP with
script-src: 'unsafe-inline', which is called unsafe for obvious reasons.It would be nice to have an astro config option, or a configration attribute for script tags, to instruct astro to create a javascript file for the bundled javascript, and then reference that file via a src attribute on the rendered script tag, instead of inlining the bundled javascript.
(During devlopment
npm run devthe processed javascript is actually linked via a script src already, making dev builds and production builds behave differently with some content security policies).The same could be done for stylesheets, making it configurable whether the stylesheet is inlined in the page (requiring style-src unsafe-inline), or included via a link.
Beta Was this translation helpful? Give feedback.
All reactions