Trust & Security

• Passwords are stored only as an argon2id hash. We cannot read your password. If you sign in with an emailed code instead, no password is stored at all.
• Emailed sign-in codes are stored hashed, expire after 10 minutes, and stop working after 5 wrong attempts.
• Two-factor authentication with an authenticator app (TOTP) is available in Settings, with one-time recovery codes. The authenticator secret is stored encrypted and recovery codes are stored only as hashes. It is optional: you turn it on for your own sign-in.
• The session cookie is httpOnly, SameSite=Lax, and Secure in production. Sessions last 30 days.
• Settings lists every signed-in device, with its last activity and IP address, and lets you sign any of them out. It also shows your recent sign-in attempts, failed ones included.
• When your account is signed in from a device we have not seen before, we email you an alert. The email is sent on a best-effort basis, so a mail outage can delay it.
• Team members are invited with a role (Owner, Admin, Manager, Editor or Viewer), and every change is checked against that role on the server. Every member can see every location in the account; access is not yet limited per location.
• An audit log records who made key changes to the account and when, and Admins can export it as CSV. It does not yet cover every action.

• You connect through Google's own OAuth consent screen. We never see your Google password.
• We request three scopes: https://www.googleapis.com/auth/business.manage (read and manage your Business Profiles: listing details, posts, reviews and replies), plus openid and email (to identify which Google account you connected).
• Google access and refresh tokens are stored encrypted with AES-256-GCM. The key is held in the server's environment configuration, not in the database, so a copy of the database alone does not contain usable Google tokens.
• An account Owner or Admin can disconnect a Google connection. That revokes GMB Pro's access at Google. The locations and their history are kept, not deleted, so they can be reattached by connecting again; deleting the account is how that data is deleted. You can also remove our access from your Google Account's third-party access settings at any time.
• The app is served over HTTPS.

• Every customer who opens one of your review links sees the same two options, in the same order: leave a public Google review, or send private feedback.
• No rating is asked for before that choice, and nothing on the page varies by who the customer is or how they might rate you. There is no field in our data model that routes a reviewer by sentiment. In other words, no review gating.

• Export. The account owner can download everything we hold about the account as one JSON file from Settings: locations, posts, reviews and replies, private feedback, rank scans, reports, team members, billing records and sign-in history. Credentials (password hashes, two-factor secrets, Google tokens, session tokens, API-key hashes and invite or review-link tokens) are never included.
• Deletion. The account owner can delete the whole account from Settings after typing the account name to confirm. Deletion is immediate and complete: workspaces, locations, posts, reviews, reports, private feedback, citations, the connected Google tokens, billing history and team access are removed in a single database transaction, and generated image files are then removed from the server (any file that cannot be removed is logged so it can be cleaned up by hand). Team members who belong to no other account are deleted with it.
• There is no recovery window. Deletion cannot be undone. It does not touch your listing on Google itself. To have Google show our access as removed too, disconnect Google before deleting the account.
• Database backups are nightly and kept for 14 days, so deleted data can remain in a backup for up to 14 days before that backup expires. The backups are stored on the same server as the database.
• Deleting an account writes one operational log line (account id, name, slug, row counts and image file paths) to our server logs. We keep it so an interrupted deletion can be finished by hand; it is not erased with the account.
• We do not sell your data, and we do not use it to train AI models. See the Privacy Policy.

• GMB Pro runs on an AWS Lightsail server in Mumbai, India (ap-south-1). The PostgreSQL database, the job queue and generated images are on that server.
• That server also runs other applications. GMB Pro has its own database role and database on it.
• This is not a data-residency guarantee. Our own server is in Mumbai, but the sub-processors below process the data they receive on their own infrastructure, and we have not committed to where.

These are the third parties our code sends your data to. We list only what the application actually calls.

We do not use advertising or analytics services, and the site sets no advertising or analytics cookies.

• No third-party audit or certification. GMB Pro does not hold SOC 2, ISO 27001 or any similar certification, and has not had an independent penetration test.
• No uptime commitment. We do not offer a service level agreement.
• Backups are not yet copied off the server. Nightly backups protect against a bad update or an accidental delete, but they live on the same server as the database, so they would not survive losing that server.
• Encryption is applied to specific secrets, not claimed for everything. Google tokens and authenticator secrets are encrypted by the application as described above. We do not claim that the database as a whole, or its backups, are encrypted at rest.
• Generated post images are served from public, unguessable URLs because Google fetches them when a post is published. Anyone with the exact URL can open the image.
• Two-factor authentication is optional and is not yet required for any account.

To report a vulnerability, ask a security or data question, or request a copy or deletion of your data, email gauravfeel@gmail.com. There is no bug bounty programme.