Web security

Most session theft in a browser app is a script reading a token, a form posting from another site, or an authorization code landing on the wrong host. Authdog's defaults close the first two for the hosted cookie. You still own the headers on your own origin, and you still have to check webhook signatures.

The session cookie

After sign-in, Authdog sets authdog-session:

• HttpOnly: page JavaScript cannot read it. An XSS bug on your origin can still act as the user while the cookie is sent, but it cannot exfiltrate the token to another host as easily.
• SameSite=Lax: the browser will not attach the cookie to cross-site POSTs. That is the CSRF control for cookie sessions.
• Secure in production: the cookie is not sent over plain HTTP.

A bearer token in Authorization does not get those protections. Anything that can read your client storage can replay it until expiry. Prefer the cookie for a first-party web app. Use the bearer for mobile, a SPA calling your API from a context that cannot use the cookie, or a service.

Your app's headers

Authdog does not set a Content-Security-Policy on your origin. You do. A CSP that blocks unexpected scripts is what keeps an injected tag from running in the first place. The HttpOnly cookie is the backstop if that policy fails.

Start from this policy and add the hosts your app actually loads:

Content-Security-Policy:
  default-src 'self';
  script-src 'self';
  connect-src 'self' https://*.authdog.com;
  frame-src https://*.authdog.com;
  img-src 'self' data: https://*.authdog.com;
  style-src 'self' 'unsafe-inline'

connect-src is the userinfo and token calls. frame-src is the hosted sign-in iframe, if you embed it. Drop unsafe-inline from style-src when your CSS does not need it. Add a CAPTCHA host here only if the challenge runs on your origin. Hosted Authdog pages send their own headers.

Also send your pages over HTTPS only. The Secure cookie flag does not upgrade a page you served as HTTP.

Redirects

An OAuth redirect is a capability. If an attacker can choose the URI, they receive the code.

Redirect URIs are checked against your verified domains. The match is exact, including scheme, port, and trailing slash. https://app.example.com/callback does not match https://app.example.com/callback/. A mismatch fails as redirect_uri_mismatch before the user sees a sign-in form.

Set them per environment under Redirects. dev can point at localhost. production should not. See Redirects.

Hosted pages

Trusted domain reminder (Authentication > Features) shows "Only sign in if you recognize this address" with the identity host on hosted sign-in and sign-up. Turn it on when users might be phished toward a lookalike host. It does not scan the user's mail. It only labels the page they are actually on.

Custom domains serve those pages on your hostname. The reminder should show the host you expect users to recognize. See Custom domains.

Webhooks

Events you subscribe to are easy to forge if you trust the JSON alone. Authdog signs the body with HMAC in X-Authdog-Signature: t=...,v1=... and retries delivery.

Verify the signature and reject a timestamp that is too old before you create a user, revoke a seat, or send mail. The steps are in Events and webhooks.

Related