Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.fim.ai/llms.txt

Use this file to discover all available pages before exploring further.

FIM One takes security seriously. If you discover a vulnerability, we want to hear about it — and we will credit you for responsible disclosure.

​
Reporting Vulnerabilities

Do NOT open a public GitHub issue for security vulnerabilities. Use one of the private channels below.
Two ways to report:
  1. GitHub Security Advisories (preferred) — Create a private advisory. Only maintainers can see it until a fix is released.
  2. Email — Send details to security@fim.ai with a description, reproduction steps, affected versions, and impact assessment.
For low-severity issues (e.g., missing security headers that don’t expose sensitive data), you may open a regular GitHub issue with the security label.

​
Response Timeline

StageTarget
AcknowledgmentWithin 48 hours (business days)
Initial assessmentWithin 5 business days
Fix developmentCritical: ASAP. High: 2 weeks. Medium/Low: next release.
Public disclosureAfter the fix is released and users have had time to update

​
Scope

​
In scope

  • Authentication and authorization bypass
  • SQL injection, command injection, or code execution
  • Cross-site scripting (XSS) or cross-site request forgery (CSRF)
  • Credential or API key exposure
  • Privilege escalation between users or organizations
  • Data leakage across tenant boundaries

​
Out of scope

  • Vulnerabilities in third-party dependencies (report upstream; we monitor via Dependabot)
  • Social engineering attacks
  • Denial of service (DoS) without a realistic attack vector
  • Issues in the demo/cloud environment that don’t affect self-hosted deployments

​
Self-Hosted Security Best Practices

If you are running FIM One on your own infrastructure, follow these recommendations to harden your deployment.
These practices apply to production deployments. For local development, the defaults are fine.
PracticeDetails
Protect .envKeep it out of version control (.gitignore includes it by default). Restrict file permissions to the application user only.
Strong JWT_SECRET_KEYUse a cryptographically random value (at least 32 characters). Never reuse secrets across environments.
Reverse proxy with TLSRun behind nginx, Caddy, or a cloud load balancer with HTTPS enabled. Never expose the application port directly to the internet.
Use PostgreSQLSQLite is suitable for development and single-user setups. For multi-user production deployments, use PostgreSQL for proper concurrency and data integrity.
Keep up to dateRegularly pull the latest release. Security patches are backported to the previous minor version on a best-effort basis.
Limit network accessRestrict database and application ports to trusted networks. Use firewall rules or security groups.

​
Security Hall of Fame

We credit all confirmed vulnerability reporters (unless they prefer to remain anonymous). Reporters also qualify for the Pioneer Program. Be the first security researcher credited here.

​
Full Security Policy

This page summarizes the key points. For the complete security policy, see SECURITY.md on GitHub.