-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: env leak detection #11203
feat: env leak detection #11203
Conversation
🦋 Changeset detectedLatest commit: 4eee601 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It took me a while to understand that this middleware needs to inspect the Response
. I would highlight this important detail, because putting this middleware on the front could allow users to change the secrets before the check.
If you're using `astro:env`, you can now use a middleware to detect server envrionment variables leaks on the client: | ||
|
||
```ts | ||
import { leakDetectionMiddleware } from 'astro/env/middleware' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we should make this astro:env/middleware
instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it makes things a bit more complicated. There's no codegen involved for the middleware code so I'm a bit reluctant to move it to a virtual import. We were also doing this for astro:env/setup
and ended up moving it to astro/env/setup
Co-authored-by: Emanuele Stoppa <[email protected]>
Let's set up a call and discuss this feature. Although it's very cool, I worry that the maintenance burden might be too high and not sure if we should take it on. But open to discussing for sure. We can set up a maintainers call to go over it. |
We need a proper RFC, this is a sensitive feature |
Changes
leakDetectionMiddleware
is exported fromastro/env/middleware
. If a server var ends up on the client, an error will be thrown. Inspired by DMNOTesting
Added a test
Docs
Changeset, I'll update the RFC after approval