How to review authentication, authorisation, secrets, input limits and least privilege as explicit trust boundaries in a Python backend.

Production principle

Authenticate identity, authorise each action and resource, constrain every input and grant each runtime component only the authority it needs.

01

Draw the trust boundaries

Requests, queue messages, files, webhooks and data returned by other services are inputs from outside the current trust boundary. Internal traffic is not automatically trusted simply because it travels through a private network.

For each boundary, record how identity is established, which claims are accepted, how freshness is checked and what happens when verification is unavailable. This turns security from scattered middleware into an inspectable system property.

02

Authentication is not authorisation

Authentication establishes who or what is making a request. Authorisation decides whether that identity may perform this action on this resource. Checking only for a valid token leaves object-level access and privileged operations exposed.

Keep policy close enough to the application operation that required context is available. Test horizontal access between users, vertical access between roles and changes in resource ownership. Default to denial when required policy data cannot be loaded.

03

Constrain data and resource use

Schema validation should bound size, shape and accepted values before expensive work begins. Limits are necessary for uploaded files, request bodies, pagination, regex processing and fan-out to downstream services.

Parameterised SQL protects query structure, but it does not prevent an authorised query from returning excessive data. Combine validation with row-level ownership checks, pagination limits and response filtering.

  • Return stable error contracts without exposing internal stack traces.
  • Rate-limit sensitive and expensive operations according to abuse risk.
  • Treat webhook signatures, timestamps and replay protection as one verification protocol.
04

Secrets and least privilege

Secrets should enter through the deployment environment or a managed secret system, never source control, images or client-visible configuration. Rotation must be possible without rebuilding application logic, and logs must redact both secret values and credentials embedded in URLs.

Give the runtime identity only the database, queue, storage and API permissions its responsibilities require. Separate deployment authority from application authority. Production evidence includes not only a policy document but an actual denied operation outside the service's intended scope.

Continue the inspection

Explore all engineering notes.

Use PRODUCTION-7 to connect this concern with the other dimensions of a trustworthy backend.

View all articles Get the checklist