Booking system security checklist

• Staff and owners see only their business (RLS on business_id plus role checks: owner, manager, staff sees own calendar); customers act on a booking only via an unguessable, hashed manage token or their authenticated account; all IDs are re-verified against business ownership (no IDOR).
• Start times are validated server-side against availability rules, time off, min notice, max advance and the slot grid; client-supplied durations, prices and end times are ignored.

• Manage links carry 32 random bytes stored only as a hash, expire after the appointment, and are scoped to one booking; cancel and reschedule re-check policy server-side every time.

• Public availability and booking endpoints do not reveal other customers' names, contact details or reasons for unavailability (only free or busy), and customer-by-email lookups return generic responses to prevent account enumeration.

• Customer name, email, phone and appointment notes (potentially health or other sensitive data) are minimised, access-controlled by role, excluded from logs and reminder job payloads (reference ids only), exportable and erasable, with anonymisation after the retention period.

• Reminder content carries no sensitive notes; SMS requires explicit opt-in with STOP handling; every message has an unsubscribe or opt-out path and is sent only through the capped notifier.

• GDPR (applies to EU users): Customer and appointment data is personal data: lawful basis, consent for marketing, export and erase endpoints, retention with anonymisation, and processor agreements for email/SMS providers.
• HIPAA / health data (applies to healthcare practitioners): Clinic and therapy bookings may include health information: avoid storing diagnoses in notes, require a BAA with all processors, and use minimum-necessary reminders; a HIPAA-covered deployment needs a separate review.
• TCPA / SMS consent (applies to SMS reminders in the US): SMS reminders require recorded opt-in, STOP/HELP handling and quiet-hours limits.
• Consumer cancellation law (applies to paid bookings): State cancellation windows, refund rules and no-show fees clearly before payment; keep proof of acceptance (booking_events).
• Accessibility: WCAG 2.2 AA: keyboard-operable calendar and slot picker, screen-reader labels with time zone, no colour-only availability cues.

• sms per business day: capped by SMS_DAILY_CAP_PER_BUSINESS and a platform-wide daily budget; over the cap SMS is refused and email is used.
• emails per business day: capped by REMINDER_DAILY_CAP_PER_BUSINESS; confirmations are reserved first, marketing dropped first.
• refund exposure cents per day: per-business daily refund ceiling; above it refunds queue for owner approval.
• availability queries per ip min: rate limited at the edge and in Postgres; cached 15 s so bursts do not hit the database.
• calendar sync api calls per day: per-connection and per-business budget when sync ships; exhausted budget pauses sync, not bookings.
• series materialised rows per run: bounded by MAX_SERIES_OCCURRENCES and the 90-day horizon.

Forge64 gives every app its own Postgres database and runs a quality gate that flags unauthenticated writes and secrets in client code before you see the app. It does not replace your own testing, and it holds no third-party security certification today.

This is a reference design for the category, not a promise that every item is generated today. Built-ins such as email, background jobs, file uploads and search are coming soon, so anything here that needs them is something you add yourself for now.

• Sign in as two different users and try to open each other's records by changing the id in the address.
• Submit each form with an empty value, a very long value and a script tag, and check the result.
• Call each write endpoint without signing in and check that it refuses.

What is the biggest security risk in a booking system?

Staff and owners see only their business (RLS on business_id plus role checks: owner, manager, staff sees own calendar); customers act on a booking only via an unguessable, hashed manage token or their authenticated account; all IDs are re-verified against business ownership (no IDOR).

Does a booking system have compliance obligations?

GDPR, if you have EU users: Customer and appointment data is personal data: lawful basis, consent for marketing, export and erase endpoints, retention with anonymisation, and processor agreements for email/SMS providers. This is a starting point, not legal advice.

Will Forge64 certify my app as secure?

No. Forge64 holds no third-party security certification today and does not certify apps. The checklist is a way to test your own app.

• How to build a booking system
• Booking system architecture
• Example prompt for a booking system
• Booking system scaling checklist
• Often combined: SaaS dashboard
• Often combined: marketplace
• All app types