Security is built into how MagicScribe works, not bolted on afterwards. This page describes the specific measures we take to protect your account, your content, and your voice data.
All communication between your browser and MagicScribe is encrypted using TLS (Transport Layer Security). We do not serve any content over plain HTTP once your account is involved.
Requests to third-party APIs (OpenAI, Anthropic, Stripe) are also made over TLS with certificate verification enforced. We do not disable SSL verification in any production context.
Your password is never stored in plain text. We use PHP's password_hash() with the bcrypt algorithm, which is a slow, salted hashing function designed to be resistant to brute-force attacks. Your plain-text password is never logged, transmitted, or stored at any point.
Every state-changing form submission includes a cryptographically random CSRF token tied to your session. Requests without a valid token are rejected. This prevents cross-site request forgery attacks.
Login attempts are rate-limited per IP address (10 attempts per 15 minutes) and per email address (5 attempts per 15 minutes). Registration is similarly limited. Exceeding these limits results in a temporary block with a clear error message.
All public-facing forms include hidden honeypot fields that are invisible to real users but filled in by bots. Any submission that includes a value in these fields is silently rejected.
Voice recordings made in MagicScribe are handled with a minimal-retention approach:
Your documents, forms, and submissions are stored in a MySQL database. All database queries use PDO prepared statements, which prevent SQL injection attacks. Database credentials are stored in environment configuration, not in the application source code.
Uploaded files (such as images embedded in documents) are validated for type and size before storage. Uploaded files are stored outside the web root where possible, or served through a controlled delivery endpoint to prevent direct script execution.
We never store card numbers or CVV codes. All payment data is handled entirely by Stripe and subject to their PCI DSS compliance programme. We store only a Stripe customer reference and your subscription status.
HTTP security headers are sent with all responses, including X-Content-Type-Options, X-Frame-Options, and Referrer-Policy, to reduce exposure to common browser-based attacks.
User-supplied data is validated before processing and escaped before output using htmlspecialchars(), preventing cross-site scripting (XSS) attacks.
Sessions are server-side only. Session cookies are marked HttpOnly (inaccessible to JavaScript) and Secure (HTTPS only) in production. Session IDs are regenerated on login to prevent session fixation attacks.
Internal API endpoints verify that requests originate from the same site before processing them. Unauthenticated requests to protected endpoints return a 401 or 403 response immediately.
We rely on the following third-party services for core functionality. Each maintains their own security programme:
We review the security posture of all third-party integrations before use and monitor for changes to their terms and policies.
If you discover a security vulnerability in MagicScribe, please let us know before disclosing it publicly. We will acknowledge your report within 48 hours, investigate promptly, and credit you if you'd like.
Please do not access, modify, or delete user data as part of your testing — read-only proof of concept is sufficient.
Report vulnerabilities to:
For security questions or to report a non-urgent concern, email [email protected]. For general support, contact [email protected].