Web Security

A secure Daml model can still be broken by an unsafe web application. The backend, browser, identity provider, database, and Ledger API connection are all part of the security boundary.

• Use a maintained OIDC or OAuth 2.0 library.
• Validate token signature, issuer, audience, expiry, and token type.
• Use short-lived access tokens.
• Require phishing-resistant MFA for administrators.
• Map the authenticated user to ledger parties on the server.
• Never trust actAs, readAs, tenant ID, role, or owner from the request body.
• Check permission for every read, command, export, search, and admin action.
• Use deny-by-default rules.
• Give each service only the ledger rights it needs.
• Test users with the same role against each other's records.

Digital Asset's Ledger API authorization guide explains how participant nodes validate access tokens and ledger permissions.

• Return only the contract fields required by the current screen or operation.
• Apply party and tenant filters before copying ledger data into an index or application database.
• Scope caches and queues by tenant and permission; never use a shared cache key for private contract results.
• Remove contract payloads, party identifiers, tokens, and onboarding secrets from logs, analytics, traces, and support tools.
• Apply the same access checks to exports, background jobs, and administrator tools as to normal API requests.

Canton privacy does not protect data after the application copies it into a database, log, cache, or browser. Our Daml privacy research and EVM-to-Canton guide explain why visibility must be reviewed across the whole system.

• Validate every request with a strict schema.
• Set limits for length, range, format, list size, and nesting.
• Recalculate important values on the server.
• Do not trust a browser-supplied fee, balance, exchange rate, or final amount.
• Show the exact action, amount, asset, counterparty, fee, and deadline before confirmation.
• Bind confirmation to a server-side operation ID.
• Expire old confirmations.
• Use idempotency keys for retryable actions.
• Protect file uploads and outbound URL requests.
• Report success only after the ledger confirms the operation.

The OWASP Transaction Authorization Cheat Sheet describes the "What You See Is What You Sign" principle and server-side transaction verification.

• Review AI-generated authentication, authorization, and payment code line by line.
• Prefer an established wallet SDK over custom browser-to-ledger connection and signing code.
• Do not paste secrets, customer data, private source code, or findings into unapproved AI tools.
• Check generated code for missing error handling, unsafe defaults, and made-up library functions.
• Require tests based on the security requirement, not only the generated code.
• Pin dependency versions and review lockfile changes.
• Remove unused packages.
• Scan dependencies, containers, source, and secrets in CI.
• Verify that the deployed artifact is the reviewed artifact.

For Loop Wallet integrations, the Five North Loop SDK provides connection, holdings, gas estimation, submission, deduplication, and transaction-update APIs. Validator-hosted applications should also understand the official Splice Wallet workflows.

• Use secure, HTTP-only cookies for browser sessions.
• Protect cookie-based state changes against CSRF.
• Rotate refresh tokens and revoke sessions after account changes.
• Require recent login for key export and admin changes.
• Keep production secrets in a secrets manager.
• Separate build, deployment, and runtime credentials.
• Log actor, action, target, result, time, and correlation ID.
• Alert on repeated login failures, permission changes, unusual exports, and new admin sessions.
• Trace a web request through the backend to the ledger result.
• Define safe behavior when the identity provider or ledger is unavailable.

Use the Cloudflare DDoS Protection documentation for managed edge controls and OWASP ASVS as the broader web application verification baseline.