Skip to main content

Security

Effective 2025-01-15v1.0

Summary

TAB POS is built with security as a foundational requirement. We use industry-standard encryption, leverage trusted infrastructure providers (Supabase, Stripe, Vercel), enforce role-based access controls, and maintain strict data isolation between restaurant tenants. This page describes our security architecture and the measures we take to protect your data.

1. Overview

TAB POS handles sensitive restaurant operational data including employee information, order details, floor plan configurations, and payment transactions. We take the protection of this data seriously and employ multiple layers of security throughout our platform.

Our security posture is built on the principle of defense in depth — no single control is relied upon exclusively. Instead, we layer protections across infrastructure, application, and operational boundaries.

2. Infrastructure

TAB POS runs on trusted, enterprise-grade infrastructure providers:

Database: Supabase (hosted PostgreSQL) with automatic daily backups, point-in-time recovery, and encrypted storage volumes.
Web Hosting: Vercel's edge network with automatic SSL, DDoS protection, and global CDN distribution.
Desktop Apps: Electron-based applications run locally on restaurant hardware, reducing cloud attack surface for core POS operations.
Payments: Stripe handles all payment data. Card numbers never touch TAB POS servers.

3. Data Encryption

All data is encrypted both in transit and at rest:

  • In Transit: All connections use TLS 1.2+ (HTTPS). API calls between desktop apps and Supabase are encrypted end-to-end.
  • At Rest: Database storage volumes use AES-256 encryption. Supabase manages encryption keys with regular rotation.
  • Backups: Database backups are encrypted using the same AES-256 standard and stored in geographically separate locations.

4. Authentication

TAB POS uses a two-tier authentication system designed for restaurant operations:

Restaurant System Unlock: An administrator (manager or owner) unlocks the restaurant system using email/password credentials. This creates a time-limited session (default 12 hours) that secures the physical terminal.
Employee Quick Login: Once the system is unlocked, staff authenticate with their employee number for quick shift transitions. This balances security with the speed requirements of restaurant service.
Session Management: Authentication tokens have configurable expiry. Sessions are invalidated on system lock or administrator logout.

5. Payment Security

All payment processing is handled by Stripe, a PCI Level 1 certified service provider (the highest level of PCI compliance).

  • Card numbers, CVVs, and sensitive payment data never touch TAB POS servers or databases.
  • Stripe Terminal readers encrypt card data at the hardware level before transmission.
  • TAB POS only stores Stripe payment intent IDs and transaction references — never raw card data.
  • Restaurants maintain their own Stripe accounts with direct access to Stripe's security dashboard and fraud prevention tools.

6. Access Control

TAB POS enforces role-based access control (RBAC) at both the application and database levels:

Staff Roles: Server, Host, Bartender, Busser, Cook — access limited to operational functions relevant to their role.
Manager Roles: FOH Manager, BOH Manager, General Manager — access to reports, configurations, and staff management.
Admin: Full system access including billing, integrations, and data export.

Database-level Row Level Security (RLS) policies ensure that queries only return data belonging to the authenticated restaurant tenant, regardless of application-level controls.

7. Data Isolation

TAB POS is a multi-tenant platform. Each restaurant's data is logically isolated through:

  • Row Level Security (RLS): Every database table enforces tenant isolation at the PostgreSQL level. Queries are automatically filtered to the authenticated restaurant.
  • API Scoping: All API endpoints validate tenant context. Cross-tenant data access is architecturally impossible through the API layer.
  • Local Data: Desktop applications cache data locally for offline operation. This data is scoped to the authenticated restaurant and cleared on system lock.

8. Monitoring & Logging

  • Infrastructure monitoring with alerts for anomalous activity, downtime, and error rate spikes.
  • Authentication events (logins, failed attempts, session expirations) are logged for audit purposes.
  • Database access logs maintained by Supabase for compliance and forensic review.
  • Application error tracking to identify and remediate issues quickly.

9. Incident Response

In the event of a security incident, TAB POS will:

  1. Investigate and contain the incident within 24 hours of detection.
  2. Notify affected restaurant administrators within 72 hours, as required by applicable data protection laws.
  3. Provide a post-incident report detailing the scope, root cause, and remediation steps taken.
  4. Implement corrective measures to prevent recurrence.

10. Employee Practices

  • Access to production systems and customer data is restricted to authorized personnel on a need-to-know basis.
  • Development follows secure coding practices including code review, dependency auditing, and automated security scanning.
  • Production database access requires multi-factor authentication.

11. Reporting a Vulnerability

If you discover a security vulnerability in TAB POS, please report it responsibly:

Email: security@tab-pos.com

Please include a description of the vulnerability, steps to reproduce, and any potential impact. We will acknowledge receipt within 48 hours and provide an initial assessment within 5 business days.

We ask that you do not publicly disclose the vulnerability until we have had a reasonable opportunity to address it.