Back to Fursa

Security & Vulnerability Disclosure Policy

Last updated: May 31, 2026

Cravid Labs LLC is the operator of Fursa (usefursa.com). Cravid Labs LLC is a Wyoming limited liability company with its principal place of business at 30 N Gould St, Ste R, Sheridan, WY 82801, United States.

Cravid Labs takes the security of the Fursa platform and the personal data of our users seriously. This policy describes the security measures we have in place to protect user data and the process for responsibly disclosing security vulnerabilities you may discover.

1. Our Commitment

We invest in industry-standard security practices and work continuously to identify and address vulnerabilities before they can be exploited. We treat security as an ongoing responsibility, not a one-time configuration. If you discover a vulnerability in our platform, we want to hear from you — and we commit to taking your report seriously, responding promptly, and keeping you informed of our progress.

2. Security Practices

The following security controls are currently in place across the Fursa platform:

  • Encryption in transit: All data transmitted between your browser, the Fursa web app, and our API is encrypted using TLS 1.2 or higher. Unencrypted HTTP connections are rejected or redirected to HTTPS. HTTP Strict Transport Security (HSTS) is enforced on all our domains.
  • Encryption at rest: Data stored in our Supabase-hosted PostgreSQL database is encrypted at rest using AES-256. This includes your profile data, career history, and AI-generated documents.
  • Authentication and session security: User authentication is handled by Supabase Auth, which issues short-lived JWT access tokens and longer-lived refresh tokens. Passwords are hashed using bcrypt with a per-user salt; we never store plaintext passwords. Row Level Security (RLS) policies in PostgreSQL enforce that users can only read and write their own data, even if a query reaches the database layer directly.
  • API rate limiting and abuse detection: Our Hono API on Railway enforces rate limits on all endpoints to prevent brute force attacks, credential stuffing, and denial-of-service conditions. Suspicious request patterns trigger automatic throttling and alerting.
  • Content Security Policy: Our Next.js web application enforces a Content Security Policy (CSP) defined in next.config.js to mitigate cross-site scripting (XSS) attacks by restricting which scripts, styles, and resources may be loaded.
  • Dependency vulnerability scanning: We run automated dependency vulnerability scans in our CI/CD pipeline on every pull request and merge to main. Critical vulnerabilities trigger blocking alerts before deployment.
  • No plaintext payment data: We do not store, process, or transmit payment card numbers or banking details. All payment processing is handled by Stripe, a PCI DSS Level 1 certified service provider. We receive only tokenized payment references from Stripe.
  • Multi-factor authentication for admin access: Administrative access to production infrastructure, databases, and deployment pipelines requires multi-factor authentication (MFA).
  • Secret management: Production secrets (API keys, database connection strings, signing keys) are managed as environment variables via Railway and Vercel secret managers. Secrets are never committed to source code repositories, logged in CI output, or passed as command-line arguments.
  • Principle of least privilege: Service accounts and internal roles are granted the minimum permissions necessary to perform their functions. Database roles are scoped to the operations each service requires.

3. Responsible Disclosure

If you discover a security vulnerability in Fursa, we ask that you follow responsible disclosure practices:

  • Contact us privately first: Email security@usefursa.com with details of the vulnerability before making any public disclosure. This gives us time to investigate and remediate before the issue becomes publicly known.
  • Include in your report: A clear description of the vulnerability; step-by-step reproduction instructions; the potential impact (data exposure, unauthorized access, service disruption, etc.); affected URLs, endpoints, or components; and your contact details if you wish to receive updates.
  • Allow time for remediation: Please allow us 90 days from the date of your report to investigate and remediate the vulnerability before publicly disclosing it. If you believe there is an imminent threat to user safety, please say so in your report and we will prioritize accordingly.
  • Data minimization during testing: Do not access, modify, exfiltrate, or delete user data beyond what is minimally necessary to demonstrate the existence of the vulnerability. Use test accounts where possible.
  • Avoid disruptive testing: Do not conduct denial-of-service attacks, load testing beyond normal usage, or any actions that could degrade service availability for other users.
  • No social engineering: Do not attempt to social engineer, phish, or otherwise deceive our team members or users as part of security research.

4. What We Pledge

In exchange for your good-faith effort to disclose vulnerabilities responsibly, Cravid Labs pledges the following:

  • Timely acknowledgement: We will acknowledge receipt of your report within 48 hours of receiving it at security@usefursa.com.
  • Status updates: We will provide a preliminary assessment of the severity and validity of your report within 7 business days, and keep you informed of our remediation progress.
  • No legal action: We will not pursue legal action against researchers who discover and report vulnerabilities in good faith, provided they act within the boundaries of this policy. We consider good-faith security research to be a benefit to our users and our platform.
  • Credit: If you wish to be acknowledged for your finding, we will credit you by name (or handle) in our security acknowledgements after the vulnerability has been remediated. Credit is optional and subject to your preference.
  • Confidentiality: We will keep the details of your report confidential during the remediation period and will not share your personal information with third parties without your consent, except as required by law.

5. Scope

The following assets are in scope for security research under this policy:

  • The Fursa web application at usefursa.com and all subdomains.
  • The Fursa API at api.usefursa.com.
  • The Fursa Chrome Extension (available on the Chrome Web Store).

The following are out of scope:

  • Third-party services and infrastructure we integrate with, including Supabase, Stripe, Anthropic, Railway, Vercel, and PostHog. Vulnerabilities in these services should be reported directly to the respective vendor.
  • Social engineering attacks targeting Cravid Labs team members or Fursa users.
  • Physical security of our offices or infrastructure facilities.
  • Denial-of-service vulnerabilities that require resources beyond a single researcher’s reasonable capacity to demonstrate.
  • Vulnerabilities in user-installed browser extensions other than the official Fursa Chrome Extension.
  • Issues in outdated or unsupported browsers that we do not officially support.
  • Self-XSS or attacks that require the victim to take highly unlikely actions.

6. Bug Bounty

We do not currently operate a monetary bug bounty program. However, for significant and well-documented findings (particularly those involving authentication bypass, SQL injection, remote code execution, or mass data exposure), we may offer:

  • Public credit in our security acknowledgements.
  • A complimentary Fursa Pro subscription for the duration of one year.
  • A personal thank-you from the Cravid Labs team.

We will evaluate each report individually. The nature and severity of the finding will determine whether a reward is appropriate.

7. Contact

To report a security vulnerability, email security@usefursa.com. If you require encrypted communication, you may request our PGP public key by emailing that address. For general legal matters, contact legal@usefursa.com.