The access we ask for
Two Google permissions and no others: sign-in (your account id, email address and name), and webmasters.readonly, the read-only Search Console scope.
Read-only is a property of the token, not a policy of ours. There is no request we could send Google that would change one of your properties, because the credential we hold is not accepted for those endpoints. You can revoke it from your Google account permissions page at any time, and the connection stops working immediately.
webmasters.readonly
Search Console, read-only
- The list of Search Console properties your account can see, with your permission level on each
- Clicks, impressions, CTR and average position for each property you connect, day by day
- The same four figures by query, page, device and country
- The id of the Google account that granted it, so each account's Google quota is counted on its own
Two Search Console calls use it: sites.list and searchAnalytics.query. Your sitemap comes from your own site, fetched the way a search engine fetches it.
openid email profile
Sign in with Google
- Your Google account id, which is how we recognise you next time
- Your email address, and whether Google has verified it
- Your name, which becomes the display name of a new account
Read once at each sign-in, to find your account or to create it.
Both permissions are listed on your Google account permissions page. Remove access there at any time and the connection stops working immediately.
How it is stored
- Google tokens are encrypted at rest with AES-256-GCM under a key held separately from the database.
- Passwords are hashed with scrypt, salted per user. We cannot read yours, and neither can anyone who takes a copy of the database.
- Two-factor authentication is available on every account, including free ones.
- Your account and analytics data are stored in the European Union, on application and database servers in Germany. The main companies that handle your data are listed on our sub-processors page.
How the application is defended
- A strict Content Security Policy with per-request nonces, so an injected script has nothing to execute under.
- CSRF tokens on every state-changing form, and session cookies that are HTTP-only and same-site.
- Rate limiting at the edge and again in the application, with stricter limits on authentication endpoints.
- Outbound requests, such as fetching your sitemap, go through an allowlist that blocks internal and private addresses, so the feature cannot be turned into a probe of our own network.
- Server-side authorisation on every request. A viewer cannot reach an editor's endpoint by typing its URL.
What runs in your browser
Two scripts on the public site come from outside, and both are Google's: the Sign in with Google prompt, which loads while you are signed out, and reCAPTCHA, which loads only on the contact and sign-up forms. Any analytics or advertising tag waits until you allow it in the cookie banner. There is no chat widget and no session recorder, because each of those would be another company running code in your browser on our behalf.
We also do not store your Google password, ever. Sign-in happens on Google's own screen and we receive a token, not a credential.
Reporting something
If you have found a vulnerability, email [email protected]. We will acknowledge it, keep you informed, and credit you if you would like.
We will not pursue legal action for good-faith research: testing only against your own account, no denial of service, no access to or modification of other people's data, no social engineering of our staff or users, and giving us a reasonable chance to fix it before publishing.
What we ask of you
- Turn on two-factor authentication. It is free, and it is the single largest improvement available to your account.
- Give teammates the smallest role that works. A client who needs reports needs viewer, not owner.
- Remove people when they leave. Roles are revoked instantly.
- Revoke our Google access if you stop using us, from your Google account rather than trusting us to have tidied up.