Security at RankRight

Last reviewed September 6, 2026 · This page describes the controls actually in place today. It is written to answer the questions security questionnaires ask; if yours asks something it doesn’t cover, ask us.

1. Summary
2. Hosting and data residency
3. Encryption in transit
4. Encryption at rest and secrets
5. Authentication and sessions
6. Tenant isolation and access control
7. API, MCP and webhook security
8. AI providers and third parties
9. Retention, backups and deletion
10. Operations and monitoring
11. Incident response
12. Vulnerability disclosure
13. Compliance status
14. Contact

1. Summary

• Hosted in the United States (Dallas, Texas) behind Cloudflare; TLS everywhere, HSTS enabled.
• Passwords are bcrypt-hashed; two-factor secrets, stored provider keys and webhook signing secrets are encrypted at rest; API keys are stored as hashes with explicit scopes.
• Optional TOTP two-factor authentication; single sign-on via OpenID Connect or SAML 2.0 (Google live; organizations add their own identity provider self-serve).
• Third-party apps and MCP clients authorize through OAuth 2.0 (PKCE, one-hour tokens, rotating refresh, revocable) rather than holding long-lived keys.
• Every organization is isolated at the API layer, deny-by-default; every API call is audited with the key or user that made it.
• Outbound webhooks are HMAC-signed; endpoints that resolve to private networks are refused.
• Defined retention periods, daily backups, deletion within 30 days of request; customer-facing incident notification within 72 hours.

2. Hosting and data residency

The application and its database run on a virtual private server operated by WHG Hosting Services in Dallas, Texas, USA, fronted by Cloudflare for DNS, TLS termination, DDoS protection and caching of public pages only. Customer data is stored and processed in the United States. We do not currently offer regional hosting outside the US.

3. Encryption in transit

All traffic to rankright.dev and app.rankright.dev is served over HTTPS (TLS 1.2+); HTTP requests are redirected. The origin server holds its own Let’s Encrypt certificates, so traffic is encrypted between Cloudflare and the origin as well as between you and Cloudflare. Strict-Transport-Security (one year, including subdomains), X-Frame-Options: DENY, X-Content-Type-Options: nosniff and a Content Security Policy are set on application responses. Calls to third-party providers (AI, ranking data, Stripe, Google) are made over TLS.

4. Encryption at rest and secrets

• Passwords are stored as bcrypt hashes; we never store or log plaintext passwords.
• Two-factor (TOTP) secrets, bring-your-own provider API keys and webhook signing secrets are encrypted with a server-held key (Fernet / AES-128-CBC + HMAC) before they are written to the database.
• RankRight API keys and OAuth access / refresh tokens are stored as hashes; the plaintext is shown or issued exactly once.
• Deploy and provider credentials live in server-side configuration files outside the code repository.
• Site credentials you store for connected CMS or hosting accounts are held in the application database on the access-controlled server and used only for the actions you request.

5. Authentication and sessions

• Email + password with bcrypt; repeated failed sign-ins trigger a 15-minute lockout for the account.
• Optional TOTP two-factor authentication (authenticator app) per user.
• Single sign-on via OpenID Connect (authorization code + PKCE) or SAML 2.0: Google for everyone; an organization owner can register their own provider (Microsoft Entra, Okta, ADFS, Google Workspace, …) with allowed email domains, so staff sign in at /login/sso and are provisioned into that organization. SAML responses must be signed (Response or Assertion) and are checked for issuer, audience, recipient, validity window and replay; an organization's provider can only authenticate people who belong to that organization. The provider’s id_token is verified against its published keys (signature, issuer, audience, expiry, nonce) and only verified emails are accepted.
• Sessions are signed tokens in an HttpOnly, Secure, SameSite=Lax cookie and expire after 12 hours.
• Password reset links are single-use, expire after 60 minutes and are stored hashed.

6. Tenant isolation and access control

• All customer data is scoped to an organization. Web users and organization API keys can only reach methods explicitly registered for their organization, and every such call validates that the client or object belongs to that organization — unregistered methods are refused, not silently unscoped.
• Roles: owner, SEO editor, web builder, viewer. Billing, membership, branding, API keys and webhooks are owner-only; viewers are read-only everywhere.
• Sensitive records (password hashes, encrypted keys, membership topology) are never exposed through the generic API surface.
• Every API call is written to an audit log with the caller (user or key), method, timing and outcome.

7. API, MCP and webhook security

• API keys carry explicit scopes (read, write, jobs), can be revoked instantly, and are rate-limited per key (120 requests per minute by default, surfaced in X-RateLimit-* headers).
• Third-party applications and MCP clients can use OAuth 2.0 instead of keys: authorization code + PKCE only, dynamic client registration, opaque access tokens that expire after one hour and refresh tokens that rotate (reuse of a rotated token or an authorization code revokes the grant). Scopes are capped by the approving member's role; viewers cannot authorize apps. Members see and disconnect their connected apps on the account page; owners see the whole organization.
• The MCP server uses the same keys or OAuth tokens, scopes, isolation, limits and audit log as the REST API — it is not a separate trust boundary.
• Idempotency keys make retries safe; mutating endpoints are disabled platform-wide during maintenance windows.
• Outbound webhooks are signed with a per-endpoint secret (X-RankRight-Signature, HMAC-SHA256 over a timestamp and the body). Endpoints must be HTTPS, and hostnames that resolve to loopback, private or link-local addresses are refused to prevent server-side request forgery.
• The public sandbox key is read-only, rate-limited and confined to a fictional demo organization.

8. AI providers and third parties

AI features send workspace content to Anthropic, OpenAI, Google (Gemini) and fal.ai under their API terms, which exclude API data from model training. Ranking data comes from DataForSEO and SerpAPI; payments from Stripe (we never see full card numbers). The full sub-processor list, with locations, is in the Privacy Policy. AI-engine observation for the AI Visibility feature asks public questions about businesses; no customer personal data is included.

9. Retention, backups and deletion

• Workspace data is kept while the organization is active; raw AI-engine payloads are pruned after 180 days; webhook delivery logs after 30 days; API and server logs are kept for security and troubleshooting, normally no more than 12 months; billing records as required by law.
• A database snapshot is taken daily and copied to an operator-controlled workstation in the United States; snapshots older than 30 days are deleted.
• Customers can export their data through the API at any time and delete clients in the app. Organization deletion requests are completed within 30 days.

10. Operations and monitoring

• Production access is limited to RankRight staff over SSH; brute-force attempts are throttled and banned automatically (fail2ban).
• Deployments are scripted and reproducible; the code is under version control with a test suite that runs before each release.
• Background jobs run under a watchdog; queue and capacity alerts email the operator; application errors are logged and reviewed.
• Third-party dependencies are reviewed and updated on a regular cadence.

11. Incident response

If we confirm a security incident affecting your data we will notify the owners of affected organizations by email within 72 hours of confirmation, describe what happened, what data was involved, what we have done, and what we recommend you do. We keep an internal record of incidents and their remediation.

12. Vulnerability disclosure

We welcome reports from security researchers. Email [email protected] with steps to reproduce; you will get an acknowledgement within 3 business days. Please do not access data that is not yours, degrade the service, or disclose publicly before we have had a reasonable chance to fix the issue. We will not pursue legal action against good-faith research that follows these rules. A machine-readable version of this policy is at /.well-known/security.txt. We do not currently run a paid bounty program.

13. Compliance status

RankRight has not pursued SOC 2 or ISO 27001 certification; as a small, focused product we prioritise the concrete controls above over audit reports. We answer security questionnaires and can sign a data-processing agreement on request. See the Privacy Policy for GDPR, UK GDPR and CCPA/CPRA commitments.

14. Contact

Security questions, questionnaires and reports: [email protected]