Securing access to source pages

Converterer fetches the source page from a publicly reachable URL. Often the page contains private data (an invoice, a customer report, a draft document) that you don’t want exposed to the open web.

Three patterns work well, listed roughly from most to least secure. Pick whichever fits your stack.

Option 1: HTTP Basic Auth

Protect the source page with HTTP Basic Authentication and pass the credentials in the capture request:

{
  "url": "https://secure.example.com/invoices/12345",
  "username": "converterer",
  "password": "a-strong-random-string"
}

See the parameters reference for the full username and password definitions. Converterer adds the Authorization header on the upstream request, your server validates it, and Chromium renders the response.

This is the most robust option if your source server can do Basic Auth. The credentials never appear in URLs, browser history, or referrer headers.

Option 2: Secret key as a query parameter

If Basic Auth isn’t convenient, generate a long random secret per document (or per session), append it to the URL, and validate it server-side:

https://app.example.com/invoices/12345?key=9bbfbbb1-dc29-42eb-bf06-86a95e2cd9da

Your endpoint accepts the URL only if key matches the expected value for that document. Treat the key as a bearer token, use a comparison that’s resistant to timing attacks, rotate or expire it after a short window.

Caveat: query strings can leak through server logs, analytics tools, or third-party scripts that read document.location. Strip the key on the server side after validating, or use short-lived signed URLs (HMAC-signed timestamps work well).

Option 3: Unguessable URLs

Make the page available at a URL containing an unguessable random component, like a UUID v4:

https://app.example.com/invoices/53304a6a-2bf4-4028-b8af-aeb7250b4e56

This is the pattern Google Drive and Dropbox use for “share with link” access. It’s the lightest-touch option and works well when:

• The document is read-only,
• The URL doesn’t need to be revoked,
• The audience for the URL is small and trusted.

It’s not appropriate for high-value documents that might end up in shared logs, screenshots, or browser histories.

What about authenticated cookies or sessions?

Converterer doesn’t carry your end users’ session cookies through to the source server. The page must be reachable on its own credentials (or unauthenticated, via one of the patterns above). If you need to capture a logged-in view of an SPA, the typical pattern is:

1. Generate a one-time render-only token on your server.
2. Build a public-ish URL that includes the token.
3. Your server serves the rendered version of the page when it sees that token.
4. Token expires after the render completes (or after a few minutes).

That gives you the security of an authenticated render without exposing real session cookies to the renderer.