Security
GetServerSide configures Google resources you own. We're explicit about what it touches, what we store, and what we haven't built yet.
Your accounts, not ours
GTM, GA4, and Cloud resources live in your own Google accounts.
Encrypted and minimal
We store only what's needed to guide and recover your setup. Your password, never.
Revoke anytime
One click in the app, or remove access from your Google account.
Honest about gaps
We list what we haven't built yet, so you can decide what's acceptable.
What GetServerSide does
It's a hosted web app. You sign in with Google, and the app calls the Google Tag Manager, Google Analytics 4, and Google Cloud APIs to audit your existing setup, build the server-side pipeline, and verify it stays healthy.
- Your GTM, GA4, and Cloud resources live in your own Google accounts.
- We store the state needed to guide, verify, and recover your setup.
- We don't host your analytics data. Events go to your GA4 properties as usual.
Google access we request
When you sign in, Google's consent screen lists the permissions, grouped by service. Here's what each group covers, and what we actually do under it.
| Service | What the consent screen shows | What we actually do with it |
|---|---|---|
| Sign in with Google | openid email profile |
Identify your account by email, and show your name and picture in the app. The same set as any "Sign in with Google" prompt. |
| Tag Manager | Read, edit, version, publish, and delete containers | Audit your containers, stage the server-side pipeline in temporary workspaces, and create and publish versions only when you confirm. We delete only the temporary workspaces we created. |
| Analytics (GA4) | Read setup and reports; create a property | Audit your setup and aggregate reports, and create a Test Server property to validate forwarded events without touching production. |
| Google Cloud | "See, edit, configure, and delete your Google Cloud data" | Read your project list, enable the required APIs, create and manage the Cloud Run service that hosts your tagging, and read logs and metrics for health checks. Nothing else. |
Why some consent lines look broader than what we do
Google's consent screen describes the full reach of each scope, not our specific use. Three lines sound alarming and aren't:
-
"Delete your containers."
The scope is named
tagmanager.delete.containers, but the only call we make isworkspaces.delete. We remove the temporary workspaces GetServerSide created during setup, never your live container. - GA4 "may contain sensitive information." This is on the reports scope. We read aggregates (event counts, page hits over a date range) to confirm the server path matches the browser baseline. We never read raw event-level user data.
- Cloud "see, edit, configure, and delete all your data." We touch five APIs: Cloud Resource Manager, Service Usage, Cloud Run Admin, Cloud Logging, and Cloud Monitoring. We never touch BigQuery, Cloud SQL, Cloud Storage, Datastore, or Compute Engine. Narrowing this to per-API scopes is being tested, and we'll update this page when it ships.
What we store
We store
- Your Google identity (subject ID, email, display name, picture URL).
- Your Google refresh token, encrypted server-side with a key separate from the session-signing key.
- The OAuth scopes you granted at consent time.
- Your project setup state: domain, profile, resource bindings.
- Audit, validation, and health-check evidence the app needs to guide and recover your setup.
- Published-version snapshots, so we can show you what changed at Go Live.
We never store
- Your Google password.
- Raw GA4 event data or user-level analytics.
- Service account private keys.
- Customer-owned OAuth client secrets.
- Plaintext refresh tokens (always encrypted at rest).
- Plaintext access tokens (not persisted at all, reconstructed on demand from the refresh token).
Where: a managed PostgreSQL database with encryption at rest and encrypted automated backups.
How long: for the life of your project. Email [email protected] to request deletion at any time.
How to revoke
From inside the app
Account → Disconnect Google. This revokes our access server-side and forces re-consent the next time you sign in.
From your Google account
Visit myaccount.google.com/permissions, find "GetServerSide," and click "Remove access."
Google doesn't currently support revoking individual scopes (for example, keeping read access but dropping write access). Revocation removes the whole app grant. If we ship per-scope downgrade as a product feature, we'll update this page.
What's still in progress
We're early. Here's what a more mature security posture would have that we haven't shipped yet. We name these so you can decide what's acceptable for your use case.
| Area | Status | What it means |
|---|---|---|
| OAuth verification | In progress | Until Google approves it, the app runs in "Testing" mode, which limits refresh tokens to 7 days. Connected users re-consent weekly during the alpha period. |
| Per-API-call audit log | Roadmap | Today the audit log is action-level (e.g. "published Publish workspace version 42"). A per-Google-API-call log is on the roadmap. |
| Narrower Cloud Platform scope | Roadmap | The current scope is broader than ideal. Narrowing to per-API scopes is being tested (see the Cloud section above). |
| Formal assessments | Not yet | No SOC 2, ISO 27001, or CASA assessment yet. The restricted-scope security assessment is the path to public OAuth verification, and it kicks off after the alpha-period scope decisions land. |
Report a security issue. Ask a question.
Email [email protected] with a security issue or a question about anything on this page.
Last updated: May 31, 2026
We take security seriously, and we show our work. Start your server-side setup.