Skip to content
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

Private Network Access Proposal / Secure and sameSite 'none' should be allowed for localhost #308

Open
2 tasks done
pozylon opened this issue Nov 26, 2024 · 1 comment
Open
2 tasks done

Comments

@pozylon
Copy link

pozylon commented Nov 26, 2024

Prerequisites

  • I have written a descriptive issue title
  • I have searched existing issues to ensure the feature has not already been requested

🚀 Feature Proposal

Introduction

When accessing insecure localhost (for ex. http://localhost:3000) from a remote hosted UI (for ex. https://sandbox.service) the natural secure configuration for the local Fastify cookie is:

domain: localhost
secure: true
httpOnly: true
sameSite: none

Why httpOnly? We don't want to allow the SPA on sandbox.service to potentially read the cookie and forward it to some arbitrary server for security reasons

Why Same-site none? Obviously we are in cross-site waters

Why secure true when we are running the local server on HTTP? Because we have to to make same-site none working. Happily, for browsers, localhost is an exception and does not require us to serve use TLS:

A cookie with the Secure attribute is only sent to the server with an encrypted request over the HTTPS protocol. It's never sent with unsecured HTTP (except on localhost)
https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#block_access_to_your_cookies

Browsers should officially allow that combination but there is two issues here in regards to Fastify Cookie:

  1. Chrome stops it's support for that combination except for Private Network CORS Header https://www.chromium.org/updates/same-site/

  2. Fastify does not send cookies secure cookies over HTTP, only when trustProxy is enabled to be insecure and an additional header is set:

x-forwarded-proto: https

Workaround

const app = Fastify({
  trustProxy: true,
});

// Workaround: Allow to use sandbox with localhost
app.addHook('preHandler', async function (request) {
  request.headers['x-forwarded-proto'] = 'https';
});

app.addHook('onSend', async function (_, reply) {
  reply.headers({
    'Access-Control-Allow-Private-Network': 'true',
  });
});

Suggestion

We should look for a more straight-forward solution to allow working in dev mode for this scenario. I'm not sure what's the best way to solve this?

  • A flag on Fastify config? allowPrivateNetworkAccess: true?
  • Extending cors and depend on that config? Support Private Network CORS fastify-cors#277
  • Lifting the need for x-forwarded-proto to be https and trustProxy be enabled when checking if a cookie can be sent to the client in general or just for localhost

Express has the same problem: expressjs/session#837

Motivation

No response

Example

No response

@mcollina
Copy link
Member

mcollina commented Dec 7, 2024

This seems correct. I don't think we should promote insecure defaults. However documenting how to solve this common case seems useful. Would you like to send a PR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants