The twelve-factor rule says an app should treat every backing service, local or third party, as an attached resource reached through a URL or credentials held in config. For security, that means one credential per resource, swappable without code changes, so you can rotate or detach a compromised one quickly.
What counts as a backing service
The methodology defines a backing service as any service the app consumes over the network as part of normal operation. Its examples include datastores, message queues, outbound email services, caches, metrics services and storage services. Third-party and self-run services are treated the same way: the code makes no distinction, and only the locator and credentials in config differ.
Each distinct service is its own resource. Two databases are two resources, not one.
Why this helps you contain damage
The security value comes from what "attached" implies.
- Swap without a code change. The methodology says a database can be replaced with one restored from backup, with the old one detached and the new one attached, without code changes. The same property lets you point an app at a fresh credential or a new endpoint during an incident.
- One handle per resource. If each resource has its own credential in config, a leak of the queue password does not open the database.
- Detach is a real option. When a third-party service is compromised, you can unplug it from a deploy and keep the rest running.
Where teams get this wrong
The pattern fails when the idea of a single resource is blurred.
- One shared database user for everything. Several services share one account, so a leak anywhere is a leak everywhere.
- Same credential across environments. Staging and production use the same key for a third-party API, so a leaked staging value works in production. See dev and prod parity from a security view.
- Admin rights where read is enough. The app connects as a database owner because it was easier at setup.
- Handles hard coded in a client library. The endpoint is baked in, which breaks the swap property.
A short checklist
- List every backing service your app calls, including email, metrics and storage.
- Give each one its own scoped credential per environment.
- Grant the minimum operations the app needs on that resource.
- Rotate on a schedule and have a documented way to attach a replacement.
- Authenticate and encrypt each connection, even inside your own network.
Network location is not authentication. Because a backing service is reached over the network, an attacker who lands in the same network segment can try the same path, so each resource should still verify who is calling.
Quick check
Is a third-party API a backing service?
Yes. The methodology treats third-party services such as email, storage and metrics providers the same as locally run ones: attached resources reached through a locator and credentials in config.
Should two microservices share one database account?
Avoid it. Separate accounts per service limit what a single leaked credential can do and make audit trails readable.
Does attaching resources through config make them secure?
No. It makes them swappable and rotatable. You still need least privilege, encryption in transit and monitoring on each connection.
Where Safeguard fits
Safeguard scans dependencies and builds SBOMs, and its reachability analysis helps you separate vulnerable packages your code actually calls from those it does not. You can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
