1. Infrastructure and transport
- GridCrew is delivered through Vercel, with application data, authentication, and private file storage provided through Supabase.
- Supported production traffic is encrypted in transit with HTTPS. Our managed infrastructure providers maintain protections for data at rest within their systems.
- Payment-card data will be entered in Paddle-hosted payment flows when billing launches; GridCrew does not store full card numbers.
2. Authentication and tenant access
- GridCrew supports password-based authentication and optional Google OAuth through Supabase Auth.
- Organization membership, roles, and board access determine what a user can view or change.
- Database Row Level Security and tenant identifiers restrict access to organization data.
- Administrators can deactivate membership and manage sensitive organization-level capabilities.
3. API and webhook security
- REST API keys are organization-scoped. GridCrew stores a SHA-256 hash rather than the plaintext key, which is shown only when created.
- Keys can be rotated or revoked, and authenticated requests are evaluated against current organization access.
- Webhook signing secrets are returned once and used to sign the timestamp and exact request body with HMAC-SHA-256.
- Webhook destinations must use HTTPS. Private, loopback, credentialed, and redirecting targets are rejected to reduce server-side request forgery risk.
- Delivery attempts are bounded by timeouts, recorded, and retried. Repeatedly failing endpoints may be disabled.
4. Attachments
- Upload permissions and download links are time-limited and issued only after an authenticated access check.
- File types and upload sizes are restricted, filenames are sanitized, and files are stored in private object storage.
- Attachments are hashed and can be scanned by a configured malware scanning provider. A workspace should not treat scanning as a substitute for endpoint protection or safe handling.
5. Application safeguards
- Sensitive server credentials stay in server-side configuration and are not intentionally exposed to browser code.
- Input schemas, authorization checks, and database policies are applied at trust boundaries.
- Committed data changes create activity records to support traceability inside a workspace.
- Dependencies, application errors, and production behavior are reviewed as part of maintaining the Service.
6. Customer responsibilities
Customers should:
- use strong, unique passwords and secure the email and Google accounts used to sign in;
- grant the least access needed, review members regularly, and remove access promptly;
- keep devices, browsers, integration servers, and dependencies patched;
- keep API keys and webhook secrets out of source code, logs, tickets, and client-side applications;
- verify webhook signatures and timestamps using the unmodified request body; and
- avoid placing specially regulated or highly sensitive data in GridCrew unless a written agreement expressly supports it.
7. Incident response
We investigate credible security events, take steps to contain and remediate them, preserve appropriate records, and provide legally required notifications. Customer cooperation may be needed to investigate activity involving its users, devices, or integrations.
8. Report a vulnerability
Send suspected vulnerabilities to support@fotomaster.com with “GridCrew security report” in the subject. Include the affected URL or feature, clear reproduction steps, and impact. Do not access other users’ data, disrupt the Service, use destructive testing, or publicly disclose an issue before we have had a reasonable opportunity to investigate.
9. Security claims
This page describes current product controls and is not a guarantee that every threat can be prevented. GridCrew does not currently claim certifications, audit reports, or controls that are not expressly listed here. Contact us if your organization needs a security review before adopting the Service.