How we protect your data and credentials.
When you add a booking-platform account, your credentials (username and password) are encrypted client-side using AES-GCM with a per-user key. That key is derived from your active session — which means Court Central operators cannot decrypt your credentials while you are logged out. Your credentials are never stored in plaintext.
Court Central uses magic-link sign-in — there is no Court Central password to steal, reuse, or forget. Each sign-in link is single-use and expires after a short window. Phishing your Court Central password is not possible because it does not exist.
All traffic between your browser and Court Central is encrypted using TLS. HTTP requests are redirected to HTTPS. HSTS (HTTP Strict Transport Security) is enforced to prevent protocol downgrade attacks.
Court Central enforces a strict Content Security Policy (CSP) with per-request nonces for all inline scripts and styles. This blocks cross-site scripting (XSS) attacks even if an attacker manages to inject HTML into the page.
All state-changing requests require a CSRF token that is bound to your session. The token is validated server-side before any action is taken. Cross-origin form submissions cannot forge requests on your behalf.
Authentication endpoints and sensitive API routes are rate-limited to prevent brute-force and abuse. Magic links that hit the rate limit are silently dropped to avoid leaking whether an email address is registered.
Court Central only stores what is necessary to provide the service. We do not sell your personal data. See our Privacy Policy for full details on data retention and processing.
If you discover a security vulnerability, please report it privately to via the contact form. We will acknowledge your report within two business days and work with you to resolve the issue before any public disclosure.
Security is a continuous process, not a checkbox. We regularly review dependencies, audit access patterns, and update our practices as the threat landscape evolves.