Security Overview
Factual security controls used by Grabr, customer responsibilities, and how to report issues.
1. Commitment
Grabr takes security seriously and implements practical controls appropriate for a small cloud product handling social publishing credentials and media. This page describes factual controls present in the current system. It is not a certification, SOC report, or guarantee against all threats.
2. Controls in place
- Transport security: production traffic is expected to use HTTPS.
- Authentication: account auth is handled by Supabase Auth with session cookies managed through SSR helpers.
- Authorization: dashboard routes require an authenticated session; workspace features rely on membership checks and database access controls.
- Secret encryption: connected-account OAuth/session payloads are encrypted at rest with AES-256-GCM using a server-held key.
- Hashed secrets: API keys and enterprise license keys are stored as hashes rather than raw values.
- OAuth hygiene: short-lived httpOnly state cookies and scoped provider permissions for LinkedIn, Google Drive, and related flows.
- Webhook verification: Whop and fal callback endpoints verify signatures or shared secrets before applying changes.
- Least privilege for jobs: Redis/BullMQ publish jobs carry identifiers rather than raw credentials; workers retrieve secrets server-side when publishing.
- Server-only credentials: service-role keys, bot tokens, and provider API keys are intended for server/worker environments, not browsers.
3. Customer responsibilities
- use strong passwords and protect account access;
- grant teammate roles carefully;
- connect only accounts you are authorized to use and rotate provider credentials if compromised;
- review content before publishing, including AI-generated media;
- for self-host deployments, secure your own Supabase, Redis, secrets, backups, and network perimeter.
4. Known limitations
- Disconnecting a social account currently marks it disconnected and does not automatically delete every encrypted token record.
- Full account self-deletion and automated export packages are not yet productized; request help via email.
- Overview dashboard may include illustrative mock metrics; treat Analytics publish metrics as the operational source inside the product.
- Third-party platforms and AI vendors have their own security postures outside Grabr’s direct control.
5. Incident reporting and responsible disclosure
If you discover a security vulnerability, email supportgrabber@gmail.com with a description, affected URLs or components, and steps to reproduce. Please avoid public disclosure until we have had a reasonable chance to investigate and mitigate.
If a personal-data incident affects cloud customers, we will notify affected customers as described in the Privacy Policy / DPA overview.
Related documents
- Privacy Policy — How Grabr collects, uses, stores, and shares personal data for cloud and self-hosted deployments.
- Acceptable Use Policy — Prohibited and restricted uses of Grabr, including content, automation, and platform rules.
- Subprocessors — Third-party services that may process data to help operate the Grabr cloud service.
- Data Processing Addendum Overview — An overview of processing roles, safeguards, and enterprise DPA terms for cloud customers.