Hasura DDN 2025-08-19

Use these rules for a Hasura DDN project whose CompatibilityConfig date is 2025-08-19, covering metadata, connectors, authentication, permissions, GraphQL, plugins, and deployment. DDN ships engine, CLI, and connectors as independently versioned components with no unified product release, so pin the project compatibility date explicitly. Older compatibility dates disable some of the validations these rules require.

Authentication boundary

• Require an explicit production authentication mode and never rely on a development, anonymous, or administrative path for ordinary client traffic. New projects default to noAuth.
• Treat alternativeModes in AuthConfig as caller-selectable, not as configuration. A client picks the mode by sending its identifier in a request header, so any weaker mode you define is reachable from ordinary client traffic — define none you would not accept on your public endpoint.
• Prefer a maintained OIDC or JWT issuer with exact issuer, audience, algorithm, key source, and claim validation over locally invented tokens.
• Pin accepted signing algorithms and key locations and reject unsigned tokens, algorithm confusion, stale keys beyond policy, and untrusted key URLs. With jwkFromUrl, DDN accepts key-compatible algorithms; enforce a narrower allowlist in a trusted authentication service when required.
• For webhook authentication, require HTTPS, authenticate Hasura to the webhook, set strict deadlines and response schemas, and fail closed on errors.
• Separate end-user, service, deployment, connector, and operator credentials and make each