feat: add origin check for CSRF protection

[ematipico]

Changes

This PR adds the origin header check for the CSRF protection.

Closes PLT-1872

Here's the RFC for more details: withastro/roadmap#879

This is a feature that is supposed to work only for on-demand pages. It should not work during the build. To enable the feature, I had considered some generic way to change the internalMiddleware that is present in the BasePipeline class, but after having a chat with @lilnasy, we decided that it felt a bit premature and decided to go for a more custom way.

The manifest inside the pipeline contains the middleware, and if the feature is enabled, the App class (the one that all adapters use) will modify the middleware to add the origin check middleware function.

The logic of the origin check is heavily inspired from SvelteKit, and adapted to match Astro.

Testing

I added new test cases

Docs

I documented new options. I am not sure about the creation of a new page. We can still create a new page later on, considering that the RFC is still open.

[changeset-bot]

🦋 Changeset detected

Latest commit: 51b6dd9

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[bluwy]

Only one comment below, but others seem simple enough! I feel like it shouldn't need the experimental flag since it's rather straight-forward, but works for me anyways.

[matthewp]

I don't think we need the experimental flag for the origin property, but if the plan is to follow up with cookie then I think it makes sense to still have the flag, as that will be a little more complicated and have potential for bugs.

[ematipico]

I don't think we need the experimental flag for the origin property, but if the plan is to follow up with cookie then I think it makes sense to still have the flag, as that will be a little more complicated and have potential for bugs.

Yes that's the plan. The cookie/token won't be as straightforward as this one, so I felt that it was better to have the experimental flag, so we could change the shape of the configuration as we please because it's part of the experimentation phase.

[matthewp]

Also we have to have experimental flag if the RFC is not merged, and that one is not, yet.

[sarah11918]

I haven't reviewed the docs here yet, but just popping in to say that I think @ematipico 's choice of where to put docs here are perfect. The changeset will have the example, then config-reference will have both the security configuration entry and the experimental flag will be documented with the others.

I don't think this calls for an entire new page yet, but I will add it to my task list (I'm reworking our sidebar/content structure this quarter) to keep an eye out for "security related things" so we can eventually have a page. Right now, the entry in config will be our documenting, if everyone's OK with that!

[sarah11918]

The only thing I have not yet reviewed here is the changeset, @ematipico !

First, I want to double check: ONLY csrfProtection: true is experimental, but security is not?

It's not clear to me which of these things is doing what, nor how they work together. Do I need to enable the experimental flag AND the security config? Can I just enable security and not the experimental flag? What extra feature am I getting from the experimental flag in that case?

So, all the individual words seem OK, but I really don't get a good handle on how these pieces fit together. THAT's what the changeset should ideally make clear!

[sarah11918]

Suggested change

	* It enables some security measures to prevent CSRF attacks: https://owasp.org/www-community/attacks/csrf
	* It enables some security measures to prevent CSRF attacks: https://owasp.org/www-community/attacks/csrf

I think we'll need to provide some more detail here. Not heavy implementation details, but like a sentence or so on HOW are you doing this or WHAT MEASURES are you taking, in lay speak. (cookies, tokens, other random words Sarah knows?) This doesn't exactly inspire trust. 😅

Ideally, think about what people will find on web pages as advice of "things they should do" in their project to protect against this, and be able to say, "Astro enables security measures recommended to protect against CSRF attacks, like [thing that people will recognize as stuff they're supposed to want/need/do] -- if this is at all possible!

[ematipico]

@sarah11918 Thank you for the feedback. Based on your thoughts, I reworked the configuration and now the experimental flags is like this:

defineConfig({
	experimental: {
		security: {
			csrfProtection: { origin: true }
		}
	}
})

Since we are still debating if it makes sense to have a top-level security object, it's best to have everything under the experimental flag to avoid confusion, and to allow us to apply any change during the experimental phase.

[sarah11918]

@ematipico This change looks great! I was even wondering whether it might be possible to just enable security by default if you opted in to the experimental flag, but you beat me to it! 🫡

[sarah11918]

Just left a few tiny nit suggestions, but otherwise, Docs is happy with this one! Great job @ematipico!

[sarah11918]

Approving for the green check!

[septatrix]

This will break form submissions when using curl for example or pretty much any other tool which is not a modern browser such as http clients in most programming languages. Another example would be load-testing tools. While some like k6 support setting custom headers this is cumbersome and not supported by everything.

A cookie based implementation would at least work with everything which has a sense of session. So not curl but at least the other stuff I listed.

[ematipico]

Hey @septatrix, thank you for your feedback, although we would prefer to channel the discussions in the relative RFC: withastro/roadmap#879

A cookie solution has been pondered, but we are still discussing if it's worth the effort considering how Astro works.