import type { Cookies } from '@sveltejs/kit';
import type { AuthLogger } from '../types.js';
export interface CsrfValidateOptions {
    /** When set, enforces the Double-Submit-Cookie pattern on top of the origin check. */
    doubleSubmit?: boolean;
    /** SvelteKit cookies handle. Required when `doubleSubmit` is true. */
    cookies?: Cookies;
    /** Cookie name holding the CSRF token (default: `urbicon_csrf`). */
    cookieName?: string;
    /** Header name carrying the echoed CSRF token (default: `x-csrf-token`). */
    headerName?: string;
    /**
     * Read the token from the `__Host-`-prefixed cookie name. Must match the
     * value used when the cookie was set (`ensureCsrfCookie`) and on the client.
     */
    hostPrefix?: boolean;
    /**
     * Sink for the one operational failure this function can report: a
     * `doubleSubmit` gate wired without `cookies`, which 403s every mutating
     * request. `createAuthHandle` passes the config's shielded logger; a consumer
     * calling `validateCsrf` standalone (a federated app gating its own
     * cookie-authenticated mutations) can pass their own. Defaults to `console`.
     */
    logger?: AuthLogger;
}
export interface EnsureCsrfCookieOptions {
    cookieName?: string;
    /** Secure attribute for the cookie. Default `true`; set `false` for non-HTTPS dev. */
    secure?: boolean;
    /** Override the SameSite value. Default `'lax'`. */
    sameSite?: 'lax' | 'strict' | 'none';
    /** Max-Age in seconds (default: 7 days). */
    maxAge?: number;
    /**
     * Use the `__Host-` cookie-name prefix. Hardens against subdomain cookie
     * injection but **requires** HTTPS — the prefix forces `secure: true` and
     * `path: '/'` regardless of the other options (the browser drops a
     * `__Host-` cookie that lacks them).
     */
    hostPrefix?: boolean;
}
/**
 * Generate a cryptographically strong CSRF token (32 random bytes, base64url-encoded).
 */
export declare function generateCsrfToken(): string;
/**
 * Validate an incoming request against CSRF attacks.
 *
 * Layer 1 (always): Origin-header check — the request's `Origin` must match
 * the server origin. GET and HEAD are skipped (safe methods).
 *
 * Layer 2 (opt-in via `options.doubleSubmit`): Double-Submit-Cookie — the
 * token in the CSRF cookie must match the token sent in the CSRF header.
 * This holds where the Origin check alone can be satisfied without the
 * attacker controlling the page — e.g. infrastructure that rewrites or
 * normalizes the `Origin` header, combined with cross-site cookies
 * (`SameSite=None`) — because the attacker still cannot read the token
 * cookie. It requires every
 * mutating caller to send that header — SvelteKit remote-function and native
 * no-JS form posts cannot, so apps using those must leave it off (docs/AUTH.md
 * → production checklist).
 *
 * Independent of SvelteKit's kernel CSRF gate, which runs *before* any hook —
 * this check is stricter (all mutating methods, all content types incl. JSON,
 * no allow-list) for every request routed through `createAuthHandle`. The
 * kernel-gate interplay and its off-switch (`kit.csrf.trustedOrigins: ['*']`,
 * resolved at build time): docs/AUTH.md → Known Limitations & Security Gaps.
 */
export declare function validateCsrf(request: Request, url: URL, options?: CsrfValidateOptions): boolean;
/**
 * Ensure the CSRF cookie is present. Called on safe requests so the client
 * has a token to echo back on subsequent mutating requests. Returns the
 * token (existing or freshly generated) for server-side rendering scenarios
 * where the token is inlined into a form.
 *
 * Cookie is **not** `httpOnly` — the pattern relies on JS being able to
 * read it and send it back in a header or form field.
 */
export declare function ensureCsrfCookie(cookies: Cookies, options?: EnsureCsrfCookieOptions): string;