Server container security checklist
A server-side tagging container receives customer data and holds credentials for every destination it sends to, which makes it a piece of infrastructure with real security consequences and one that's frequently treated as a marketing tool. The controls that matter are unexciting: least-privilege access, secrets kept out of container configuration, an endpoint that doesn't accept arbitrary input, logging that doesn't retain personal data, and an owner who notices when something changes.
Free30 minutesNo obligation
Container security · what breaks
Where teams get this wrong — Container security
- 01
Treating it as a marketing tool
It processes customer data and holds API credentials. It's infrastructure.
- 02
Shared logins for container access
Then you can't tell who changed what, which is the whole point of an audit trail.
- 03
Logging full payloads
Debug logging that retains personal data is a quiet and long-lived exposure.
Container security · the fix
What a correct implementation looks like — Container security
Named accounts with least-privilege access
No shared credentials.
Secrets stored outside container configuration
In a secret manager, not in a variable.
Endpoint validation
So arbitrary payloads can't be injected.
Logging that excludes personal data
By default, not by remembering to turn it off.
Container security · architecture
The controls
Six controls. None of them are difficult; all of them are commonly absent because the container gets treated as a tag manager rather than as a service.
- 1
Access control
Named accounts, least privilege, reviewed when people leave. Publish rights are a small group.
- 2
Secrets management
Destination API keys and access tokens stored in the platform's secret handling, not in container variables where anyone with read access sees them.
- 3
Endpoint validation
Your tagging endpoint is public. It should reject payloads that don't match what your clients send.
- 4
Data minimisation
Strip what doesn't need to leave, and don't store what doesn't need storing.
- 5
Logging and retention
Debug logging captures payloads. Confirm what's retained, where, and for how long.
- 6
Change alerting
A container publish should notify someone. An unexpected one is worth knowing about immediately.
Container security · diagnose
Common mistakes and how to validate each — Container security
Ordered by how often we find them. Each one has a specific check rather than a general instruction to be careful.
- 01
Stale access lists
Review who has access. Former staff and former agencies appear more often than you'd like.
- 02
API keys in plain container variables
Check where destination credentials are stored. Anyone with container read access can see a variable.
- 03
Debug logging left on
Check whether it's enabled in production and what it retains.
- 04
No change notification
Ask how you'd learn if someone published the container today.
- 05
Hosting account owned by an agency
Ask whose name it's in. If it isn't yours, that's a control problem regardless of the relationship.
Container security · prove
How to prove your implementation is right — Container security
Against your own records and a live payload, not against a preview screen.
Source of truth
your own access, secret and log inventories
- Access list reviewed, with named accounts and least privilege.
- No credentials present in container variables.
- Endpoint confirmed rejecting malformed payloads.
- Log retention confirmed and personal data excluded.
- Hosting account confirmed in your organization's name.
- Checked on a live conversion, not in preview mode.
- Reconciled over a fully closed window, matched per record.
- Re-checked 30 days later.
Container security · free audit
What we check in the free audit
- Stale access lists
- API keys in plain container variables
- Debug logging left on
- No change notification
- Hosting account owned by an agency
Checked against
your own access, secret and log inventories
Free30 minutesNo obligation
Container security · when not to buy
What this reference deliberately leaves out — Container security
Stated openly, because a reference that's silent about its own gaps is the dangerous kind.
- This is not a full infrastructure security review. It covers container-specific controls, not your cloud posture generally.
- Compliance obligations around data processing agreements and sub-processors are legal questions, not technical ones.
- Platform-specific security features differ per host and change; check current documentation.
- Vendor documentation is the authority, not this page. Where the two disagree, the vendor is right and we'd like to know so we can correct it.
- Parameter names and behaviour change. Anything here is accurate as we last verified it; verify against the current documentation before you rely on it for a build.
Container security · what we deliver
The checklist — Container security
Access is named, least-privilege and reviewed
Publish access is not editor access is not viewer access.
No API keys in container variables
Use the platform's secret handling.
The endpoint rejects unexpected payloads
Anyone can post to a public endpoint.
Logs exclude personal data
Check what debug logging retains and for how long.
Changes are alerted to a named person
So an unexpected publish is noticed.
Pricing
Pick the package that fits your ad spend
Browser-side starter
$400One-time fee · lifetime ownership
Repairs and verifies your existing browser-side setup against this reference, on a live conversion.
- Implementation checked against the spec
- Verified on a live conversion
- Reconciled against your own records
- Written handover
1st-party server-side
Recommended$800One-time fee · most popular
Money events sent from your own records through a first-party container on your subdomain, built to this specification.
- First-party server container on your own subdomain
- Events from your records, not the browser
- Deduplicated on a shared event ID at every destination
- First-party cookies beyond Safari's 7-day cap
- 95%+ accuracy and 8+ Meta EMQ, guaranteed in writing
Full 1st-party stack
$1,800One-time fee · lifetime ownership
Every paid channel server-side plus the offline loop, documented to this standard.
- Everything in 1st-party server-side
- Pinterest, Snapchat, Reddit and LinkedIn CAPI
- CRM and offline conversion loop
- Refunds and cancellations corrected wherever each platform allows it
- Monitoring so the next break surfaces in days
FAQ
Container security questions, answered
It's infrastructure that processes customer data and holds destination credentials. That makes it a system to secure, which is different from a risk to avoid.
In the platform's secret handling, never in container variables. Anyone with read access to the container can see a variable.
It's public, so yes. It should validate that payloads match what your clients actually send rather than accepting anything.
Your organization's. Whoever holds the infrastructure holds your measurement and your customer data, and that shouldn't be an agency.
Free · 30 min
Get your container treated as infrastructure
WhatsAppFree30 minutesNo obligation
