skip to content

How would you decide whether a Playwright suite may run every context with ignoreHTTPSErrors and bypassCSP enabled?

level: principalimportance: should knowfreq 28%

answer

  1. Both defaults are off for a reason
  2. Ask what stops failing
  3. Scope the exception, not the suite
  4. Keep one honest run without them
  5. Give every deviation an owner

basics

~20 s

Playwright's ignoreHTTPSErrors and bypassCSP are deliberate deviations from a real browser. Default both off, enable them only for the tests or environments that need it, and keep one path running with the real certificate and policy.

solid answer

~40 s

Both options make the browser behave less like the user's, so the question is how much realism you are trading and for what. `ignoreHTTPSErrors` (default `false`) accepts invalid certificates from every host the context talks to — reasonable for an internal box with a self-signed certificate, expensive because a genuine certificate regression stops failing anything. `bypassCSP` (default `false`) stops the page enforcing the security policy it serves, which is how injected scripts survive on a strict site — and it also means your suite no longer proves the app works under the policy it ships. My rule is: narrow scope over global scope (`test.use` on the file that needs it, or one environment), a written reason, and a counterweight test that still runs with the real setting so the regression has somewhere to fail.

code

typescript · 10 lines
typescript
import { test, expect } from '@playwright/test';

test.describe('room gallery fallback', () => {
  test.use({ bypassCSP: true });

  test('renders a placeholder when the image service is stubbed', async ({ page }) => {
    await page.goto('/rooms/12');
    await expect(page.getByTestId('room-gallery')).toBeVisible();
  });
});

go deeper

for a junior

Know that both options exist, that both are off by default, and that switching one on makes the browser behave less like a real user's browser.

for a middle

Explain what each option actually changes and name a concrete failure it would hide, such as an expired certificate or a blocked script.

for a senior

Show how you would scope the exception to one file or environment, and what you keep running with the real settings so the regression still has somewhere to fail.

for a principal

Own the policy: who approves a deviation, how it is recorded and revisited, and how you stop a loosened config spreading across repositories once it exists.

## The shape of the decision Both `ignoreHTTPSErrors` and `bypassCSP` are context options that default to `false`, and both buy convenience by making the browser under test less like the browser a guest booking a room will use. Neither is forbidden; the failure is turning one on globally, forgetting it, and losing the signal it suppressed. The decision is therefore not "is it allowed" but "how narrow can the exception be, and what still fails if the underlying problem comes back". ## What each one actually costs | Option | What it buys | What stops failing | |---|---|---| | `ignoreHTTPSErrors` | tests run against a host with an invalid or self-signed certificate | expired, misissued or wrongly chained certificates, on every host the context touches | | `bypassCSP` | injected scripts and stubs survive on a page with a strict policy | a policy regression that would block the app's own scripts in production | The second column is the part that gets skipped in review. A suite with `ignoreHTTPSErrors` on everywhere will happily go green the week the certificate on the booking site expires; a suite with `bypassCSP` on everywhere cannot tell you that a new inline script was blocked for real users. ## How I would scope each one 1. **Prefer fixing the environment.** A staging box with a proper certificate removes the need for the option at all, and is usually a day of work rather than a permanent hole in the suite. 2. **Scope to the smallest unit that needs it.** `test.use({ bypassCSP: true })` on the one describe block that injects a stub is far better than a global default, because the exception is visible next to the test that justifies it. 3. **Keep an honest counterweight.** At least one run — a smoke path against the real environment — should use neither option, so the suppressed failure still has a place to surface. 4. **Write the reason down and date it.** An exception with an owner and a ticket gets removed; an unexplained flag in a shared config survives forever. ## Questions I would ask before agreeing - Which host actually presents the bad certificate, and is it a host the product depends on in production? - Is `bypassCSP` compensating for a stub that could be planted before boot with an init script instead, or for a route-level substitution that never has to touch the policy? - What breaks in production if this suppression hides a regression for a full release cycle? - Does anything else in the pipeline check the thing we are switching off — a certificate monitor, a security scan, a header assertion? ## The organisational half These flags spread. One project turns on `ignoreHTTPSErrors` for a staging box, the config is copied into the next service's repository, and two years later nobody can say which host needed it. The durable controls are ownership and visibility: a named owner for each deviation, a review rule that any change to security-shaped context options needs a second opinion, and a periodic pass that tries removing each one to see whether the suite still passes. If it does, the exception is dead and should go. ## The answer I want from a candidate Not "never do it" and not "it is fine on staging", but a framework: what the option suppresses, how narrow the exception can be made, what still fails if the real problem returns, and who owns removing it. A lead who can also name the cheaper fix — a valid certificate, an init script instead of an injected tag — is demonstrating that the option is a last resort rather than a habit.

  • How would you prove an exception like this is still needed a year later?
    Remove it and run the suite. A periodic pass that deletes each deviation and watches what fails is the only reliable audit; anything else relies on memory. Exceptions that pass without the flag are dead and get deleted in the same change.
  • Is there a cheaper alternative to bypassCSP for injecting a stub?
    Often, yes. Planting the stub with an init script before the page's scripts run avoids adding a script tag the policy would reject, and substituting the response at the network layer avoids injection entirely. Reach for the option only when the mechanism genuinely requires evaluating code the page's policy forbids.
  • What would make you accept ignoreHTTPSErrors across a whole environment?
    A closed internal environment whose certificate is issued by a private authority the runners cannot trust, where a certificate monitor covers the production hosts separately. Even then I would scope it to that environment's project rather than the global default, and revisit it once the runner can trust the authority.

saying these in an interview costs you the question

  • Turns both options on globally to make tests pass
  • Believes bypassCSP only affects the test's own scripts
  • Thinks ignoring certificate errors is harmless on staging
  • Cannot say what failure the option now hides
  • Copies a loosened config into the next repository unchanged