Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Scan browser runs without Chromium's sandbox

Ouverte
  • Quelque chose ne va pas ?
#331 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@eparenti y travaille déjà.

Depuis le 29/10/2026.

  • #342 par @eparenti — ouverte

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
46/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
Active
Stack technique
playwright, typescript
Domaine
security, testing

Piste de recherche

Start in src/deps/real.ts at makeSharedBrowser and trace how launch failures, run output, doctor findings, and Result coverage are represented. Read the existing config and threat model, then locate the relevant tests and add coverage for default sandbox launch, all three fallback disclosures, and require refusing with exit 4. Done when those behaviors and the three specified CDP and browser threat model points are covered.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

area: engine security

What happens

usabl launches its scan browser with chromium.launch({ headless: true }) (src/deps/real.ts, makeSharedBrowser). Playwright adds --no-sandbox unless chromiumSandbox: true is passed, and usabl never passes it. Every page usabl scans runs without Chromium's sandbox: the app, its docs pages, and any third-party scripts they load.

Why it matters

The sandbox is what contains a page that exploits a Chromium rendering bug. Without it, such a page runs code with the rights of the user running usabl. That user can read the repository, local keys, and the signed-in session from USABL_STORAGE_STATE. In CI, it can read the runner's tokens.

Decision

  • Launch with the sandbox on by default.
  • When the system cannot provide a sandbox (for example Ubuntu 23.10 and later with restricted user namespaces, or many containers), fall back to an unsandboxed launch and disclose it: a line in the run output, a usabl doctor finding with the fix, and a note in the Result's coverage section. The fallback changes no verdict.
  • A config option (for example "browserSandbox": "require") refuses to scan unsandboxed: exit 4 with a message that says how to enable the sandbox.
  • Tell a sandbox failure apart from other launch failures, so a missing Chromium or a crash is not reported as a sandbox problem.

Acceptance

  • A test proves the default launch asks for the sandbox.
  • A test proves the fallback is disclosed in all three places.
  • A test proves require refuses with exit 4.
  • The threat model gains a section on CDP and the browser covering three points. First, CDP runs over a pipe and no port is opened. Second, page-world reads versus isolated worlds. Third, the sandbox, plus a note that a caller's own browser passed to checkPage is the caller's exposure.

Notes

Checked on 2026-10-27. A scan browser carries --remote-debugging-pipe and --no-sandbox, and ss shows no listening TCP socket owned by it. A sandboxed launch works on a Fedora 43 host.

Langage dominant
TypeScript
Étoiles
0
Forks
0
Merge moyen
6 h 42 min
PR mergées (30 j)
44

Préparer son environnement

  • Aucun Dockerfile ni fichier Docker Compose
  • Propose un modèle de pull request
  • Aucun guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de usabl-dev/usabl

Toutes les issues de usabl-dev/usabl

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.