Browse documentation

Documentation overview

Tutorial

Reference

Project

Deployment boundaries

Wred gives you HTTP primitives. You choose the protections around them. This page names those boundaries so they don’t become surprises with an incident number.

Bound request size and direct access

request.body() buffers the entire body without a built-in size limit. Apply a limit in the ASGI server, middleware, or reverse proxy before the app reads it. The Caddy and Nginx examples include body limits.

Bind a same-host backend to loopback and expose only the proxy. For separate hosts, use an appropriately restricted private connection. Trust forwarded headers only from the proxy peers you control.

Authentication and ownership are application rules

The notebook validates opaque bearer credentials and filters data changes by owner. Its custom request.user attribute comes from its decorator. An unrelated Wred application gets none of that automatically.

Choose account recovery, credential expiry, revocation, and abuse controls for the application you are shipping. Read the notebook walkthrough before copying its login flow. A decorator name is not a security review, however reassuring its spelling.

Keep browser credential rules coherent

The notebook expects same-origin login and refresh requests with its custom header. Its refresh cookie is HttpOnly and SameSite=Strict, and gets Secure when the incoming ASGI scheme is HTTPS. Correct proxy scheme handling is therefore part of the login behavior.

CORS controls browser cross-origin access. Enabling it alone does not remove the notebook’s same-origin checks or supply CSRF protection for another app. If you adapt the auth flow to another origin, revise the origin, cookie, credential, and CSRF behavior together.

Starlette’s signed-cookie session recipe is separate: signing detects tampering but does not encrypt the contents. Store secrets on the server.

Validate data and render text safely

Validate JSON shape, string lengths, numbers, and allowed fields. Wred does not impose schemas. Keep ownership in authenticated server context rather than accepting it from an incoming JSON object.

The notebook frontend uses textContent for user text. Avoid interpolating untrusted note contents into HTML. Keep credentials out of URLs, logs, screenshots, and committed environment files.

Keep diagnostics useful

Log unexpected failures at the server or middleware layer while returning intentional public error bodies. Disable public tracebacks in deployment. Preserve request IDs if you add them, and avoid logging passwords, bearer tokens, or cookie values.

Check startup, login, a protected operation, and logout through the actual public domain. A successful backend health request proves considerably less than the whole application working.

Report problems with enough context

For ordinary bugs, see the reporting checklist. For a suspected vulnerability, use an appropriate private contact channel with the maintainer before posting exploit details publicly. These docs do not announce a separate disclosure program or response-time guarantee.

Share the affected version and a minimal reproduction without production data or credentials. The project repository and its package metadata identify the maintainer.