w3c / w3c/ServiceWorker

Add a Service-Worker-Exclude Header

Open
#1,690 8 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Bikeshed
Stars
3.6k
Forks
324
Avg merge
14d 22h
Merged PRs (30d)
1

Description

I'm currently developing an SSO solution, and ran into some difficulties: https://github.com/Daniel-Abrecht/dpa-sso#security-relevant-limitations

To sum it up, I can't rely on cross origin cookies to store a session token, because browsers allow disabling them nowadays. For that reason, I pass it to a well known location at the origin which needs the token as a get parameter. If that origin has a service worker installed, it could intercept that token. For some applications, that may be desirable, but for others, it could be problematic.

I'm still looking for a safer way to pass the token, but it would be nice to also have a way to prevent a service worker from handling requests to certain locations too.

For that reason, I propose adding a Service-Worker-Exclude header, that would have some similarities to the Service-Worker-Allowed header. I would like it to work as follows. Service-Worker-Exclude should contain a list of locations who will not be handled by the service worker and just bypass it entirely. It should be set when installing the service worker. That way, I could, for example, make sure the entire /.well-known/ directory won't be handled by a service worker.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the existing Service-Worker-Allowed behavior and the proposed Service-Worker-Exclude semantics, especially how exclusions would be set when installing a service worker. Define the header's location-list behavior and verify that requests such as /.well-known/ bypass the service worker as intended.

Written by the indexing model from the issue text.

Assessment

Domain
security, web-dev
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.