Playwright 1.63 Adds Multi-Origin HTTP Credentials: Keep Proxy Authentication Separate

Microsoft released Playwright 1.63 on September 4, 2026. Among its browser-context changes, httpCredentials now accepts an array. The first entry matching the request origin is selected, while an entry without an origin can match any request.

That is useful for authorized automation spanning several HTTP-authenticated origins. It is also an upgrade boundary worth testing carefully when the same browser context uses an authenticated proxy. Origin HTTP credentials and proxy credentials solve different challenges, travel to different peers, and must not be treated as one credential pool.

Public source note: Microsoft Playwright, “Playwright v1.63.0,” released September 4, 2026; Microsoft Playwright, Browser API reference, reviewed September 10, 2026.

What Playwright 1.63 changed

Previously, a browser context accepted one httpCredentials object. Version 1.63 also accepts an ordered array of credential entries. Each entry can specify a username, password, and an exact origin. Playwright uses the first entry whose origin matches the request; an entry without an origin acts as a broad fallback.

The same release adds a codegen option for recording against pages protected by HTTP authentication. That convenience does not change the security boundary: generated code and captured artifacts still require secret review before they are stored or shared.

The change does not mean:

• HTML sign-in forms are automatically handled;
• cookies or bearer tokens are selected by origin;
• proxy authentication has moved into httpCredentials;
• a 401 response and a 407 response are interchangeable;
• credentials should be embedded in source code;
• redirects are safe without validating the final origin.

Keep the two authentication planes separate

Playwright exposes separate context options for separate peers:

const context = await browser.newContext({
  proxy: {
    server: proxyServer,
    username: proxyUser,
    password: proxyPassword
  },
  httpCredentials: [
    { origin: originA, username: siteUserA, password: sitePasswordA },
    { origin: originB, username: siteUserB, password: sitePasswordB }
  ]
});

The proxy object configures the route and, when required, authenticates to the proxy service. httpCredentials handles HTTP authentication presented by destination origins. A destination challenge normally uses status 401 and WWW-Authenticate; a proxy challenge normally uses status 407 and Proxy-Authenticate.

Do not copy destination credentials into proxy fields or proxy credentials into origin entries. Even when both use username and password strings, they belong to different trust zones.

Why ordering is a security decision

The release notes and API reference state that the first matching entry wins. Therefore array order is configuration logic, not decoration.

Prefer every production entry to declare an exact origin, including scheme, hostname, and port where relevant. Treat an originless entry as exceptional. If a broad fallback is necessary for a bounded test, place it last, restrict the navigation allowlist, and prove that no unapproved destination can trigger it.

Before deployment, lint the resolved configuration rather than only its source template. Environment overlays can reorder arrays, introduce duplicate origins, or replace an exact origin with an empty value.

Run a direct-and-proxy matrix

Use controlled origins that you own or are authorized to test. Build at least these cases:

1. direct control with origin A credentials;
2. authenticated proxy with origin A credentials;
3. authenticated proxy with origin B credentials;
4. origin A request carrying the wrong site password;
5. proxy request carrying the wrong proxy password;
6. redirect from origin A to origin B;
7. redirect to an origin with no credential entry;
8. an originless fallback, if your design intentionally uses one;
9. an API request context using each supported send policy;
10. a normal browser navigation using the same credential array.

Hold the browser build, route, target, request method, headers, and session state constant. Change one credential dimension at a time.

Use the request-header integrity test to confirm equivalent request profiles. Before sharing traces or HAR files, apply the HAR credential redaction guide carefully.

Evidence to capture

Store a sanitized record for each attempt:

browser_build
context_profile_id
route_id
proxy_auth_expected
origin_rule_id
requested_origin
final_origin
redirect_count
status_sequence
challenge_type
credential_rule_selected
body_digest
assertion_result
duration_ms

Do not record usernames, passwords, authorization values, proxy authorization values, cookies, tokens, or full customer payloads. A rule identifier is enough to prove which configuration branch was selected.

If a trace, screenshot, video, or HAR is retained, classify it as sensitive until inspected. Authentication dialogs, headers, URLs, and application content can expose more than the test log.

Interpret failures by layer

Proxy fails before the origin is reached

Investigate route selection, proxy address, proxy credential rule, tunnel setup, DNS ownership, TLS, and the 407 exchange. Changing origin HTTP credentials cannot repair a proxy-layer failure.

Origin returns 401 through both direct and proxy routes

Check the exact origin match, entry order, site credential validity, authentication scheme, and whether the browser or API request context is being used. This pattern usually points away from the proxy.

Direct succeeds but proxy returns an origin 401

First prove that the response is genuinely from the same destination origin. Compare final URL, redirects, response bytes, headers, and application routing. A regional edge, cached challenge, or different backend can explain the difference without implying that Playwright leaked or ignored credentials.

A redirect selects the wrong rule

Treat this as a configuration defect. The destination after redirect is a different origin and should be matched independently. Remove broad fallbacks unless they are required and bounded.

API requests behave differently from page navigation

Playwright documents the send control as applying to requests from the corresponding API request context, not browser requests. Test these paths independently instead of expecting one preemptive-auth policy to cover both.

Upgrade acceptance checklist

• Pin and record the exact Playwright and browser builds.
• Inventory every destination origin that requires HTTP authentication.
• Keep proxy secrets only in the proxy configuration path.
• Use exact origin matches for site credentials.
• Verify first-match behavior and reject duplicate origins.
• Put any originless fallback last and justify it.
• Test 401 and 407 failures separately.
• Test cross-origin redirects and missing credential rules.
• Compare direct and proxy routes with identical target inputs.
• Test API request contexts separately from browser navigation.
• Redact traces, HAR files, screenshots, videos, logs, and CI output.
• Define a rollback threshold before expanding the rollout.

FAQ

Does httpCredentials configure my residential proxy login?

No. Use Playwright’s proxy configuration for proxy server credentials. httpCredentials is for HTTP authentication at destination origins.

Should I add one credential entry without an origin as a default?

Usually not. A fallback can match requests that no specific entry covers. Prefer exact origins; if a fallback is required, place it last and constrain reachable destinations.

Can one context use different Basic-auth credentials for several sites?

That is the new capability in Playwright 1.63. Test exact origin matching, ordering, redirects, and failure behavior before relying on it in production.

Does the send option make browser navigation send credentials preemptively?

The Playwright reference says that control applies to the corresponding API request context and does not affect browser requests. Keep separate tests for both paths.

Compliance note

Use HTTP and proxy credentials only for systems and accounts you are authorized to access. Do not use proxy routing or automation to bypass authentication, geographic controls, rate limits, purchase restrictions, or anti-fraud systems. Store secrets in an approved secret manager, minimize retained artifacts, and respect privacy, contracts, access policies, and regional law.