Backends that have to stay up
A Python service that authenticates users and holds data is part of the security story. Reliability, access control, and hardening belong in the same backlog as features.
A backend is not a side quest you add when the interface is done. If it authenticates people, stores data, or moves money and messages, it is part of the security story whether or not anyone wrote “AppSec” on the ticket.
GlitchIdea writes and hardens Python services — Django and Flask, REST APIs, authentication and access control — with the same discipline as the pipeline around them. The service has to stay up. It also has to stay the service you think you deployed.
Stay up is a product requirement
“Stay up” is not a vibe. It is a set of boring properties:
- a release can be rolled forward and back
- configuration is explicit per environment
- workers, web, and scheduled jobs fail in a way you can see
- data migrations are part of the release, not a surprise SSH
- dependencies are pinned and reviewed when they move
Django and Flask are fine tools. They do not excuse an app that can only be run from one person’s laptop. If the team cannot bring the service up from the repository and a documented environment, hardening later will fight the architecture.
Authentication is not a middleware you paste
Most Python APIs grow a user model, then sessions, then tokens, then a second token for mobile, then an exception for a partner. Access control is scattered across views, serializers, and a couple of decorators someone was afraid to touch.
The work is to make authorisation visible:
- what identity the request has
- what resource it is asking for
- what rule allows it
- what is denied by default
Object-level checks belong next to the query, not only at the route. A list endpoint that filters in Python after fetching every row is both slow and easy to get wrong. Tenant IDs, owners, and roles should be in the query the same way they are in the threat model.
If you are adding SSO or API keys to an existing service, treat it as a feature with tests, not as a library import. Callbacks, clock skew, token revocation, and “what happens when the IdP is down” are the actual project.
Hardening what already runs
Greenfield is rare. More often there is a service in production that works, that nobody wants to freeze, and that has accumulated settings, cron, and a README from 2023. Hardening that system is a sequence, not a rewrite:
- Make a repeatable run (container or documented host, one command to boot).
- Put secrets outside the image and outside the repo.
- Turn on the access logs and error reporting you would need this week.
- Close the obvious network and debug surfaces (admin, docs, TRACE, default keys).
- Add tests around the identity paths before you change them.
- Only then reshape code that is risky to touch.
This is slower than a slide that says “zero trust.” It is faster than an outage caused by a clever rewrite.
APIs as contracts
A REST API used by a web app, a mobile client, and a partner will drift. Fields get added. Error shapes change. Versioning is postponed until a client breaks. Security issues hide in that drift: extra fields that should not be writable, verbose errors, undocumented routes that still route.
Treat the API as a contract in the same repo as the service. Schema or serializer tests, a changelog the client team can read, and authz tests for the routes that matter. You do not need a platform team of twenty to do this. You need the contract to exist somewhere other than Slack.
How this sits next to DevSecOps
A secure backend without a trustworthy deploy is a well-written box with an unlocked door. The inverse is also true: a hardened pipeline in front of an API that trusts the client is a locked door in front of an open window.
That is why GlitchIdea keeps backend engineering in the same practice as DevSecOps and pentest. When we write the service, we expect to ship it. When we test an application, we look at the API the service actually exposes. When we harden production, we include the runtime the Python process lives in.
If you need a service built, an existing one tightened, or both, send the stack and the outcome. Django, Flask, and the surrounding Linux and CI are all in bounds.
A concrete example
A Flask service has JWT auth, a React admin, and a Postgres database. It has been live for a year. There is one Dockerfile that still copies .env. Debug is off in production, except /debug/users was never removed. Partners call an undocumented /internal/export.
The first week is not a rewrite. It is: stop shipping secrets in the image, delete or lock the debug route, put the export behind a service identity and an allow-list, and add tests that a second tenant cannot export the first. Then you can talk about splitting modules. The security work and the reliability work are the same tickets.
