Vulnerability Disclosure Policy โ Lantern โ
Last Updated: January 4, 2026
Our Commitment โ
Lantern is committed to the security and privacy of our users. We welcome security researchers and the community to help us identify and address potential vulnerabilities.
We believe in:
- ๐ Transparency about our security posture
- ๐ค Collaboration with the security research community
- ๐ก๏ธ Continuous improvement of our defenses
- ๐ฏ Responsible disclosure that protects users
Scope โ
In Scope โ
The following are within scope for security research:
โ
Web application: https://ourlantern.app and https://dev.ourlantern.app
โ
Authentication & authorization: Login, signup, session management
โ
Encryption implementation: Client-side encryption vulnerabilities
โ
API endpoints: Firestore security rules, Firebase Functions
โ
Data handling: PII leakage, insecure storage, insufficient deletion
โ
Client-side security: XSS, CSRF, clickjacking, etc.
Out of Scope โ
โ Social engineering of Lantern staff or users
โ Physical security of offices or infrastructure
โ DDoS attacks or intentional service disruption
โ Third-party services (Firebase, Cloudflare) - report to them directly
โ Spam or content violations - use our abuse reporting system
โ Issues in dependencies - unless actively exploitable in Lantern
How to Report โ
Preferred Method โ
Email: security@ourlantern.app (coming soon - for now, use GitHub Issues for non-critical)
Please include:
- Description: Clear explanation of the vulnerability
- Impact: What could an attacker do? How severe?
- Steps to reproduce: Detailed reproduction steps
- Proof of concept: Code, screenshots, or video (if safe to share)
- Suggested fix: If you have ideas (optional but appreciated)
- Contact info: How we can reach you for updates
Encryption โ
PGP public key available on request for sensitive disclosures.
GitHub Issues โ
For non-sensitive security discussions:
- Use label:
security - Examples: Encryption best practices, architecture questions, general hardening
For critical vulnerabilities, please email directly (don't use public GitHub Issues).
What We Promise โ
Response Timeline โ
| Milestone | Timeline | Details |
|---|---|---|
| Acknowledgment | 48 hours | We confirm receipt of your report |
| Initial triage | 7 days | We assess severity and impact |
| Status updates | Every 7 days | Regular progress reports |
| Fix deployment | 30 days (critical) 90 days (non-critical) | Target timelines, may vary by complexity |
| Public disclosure | Coordinated | After fix is deployed and users updated |
Recognition โ
We offer:
- โ Credit in our security advisories (if you want)
- โ Public thanks on our website/blog
- โ Swag (Lantern stickers, shirts when available)
- ๐ Bounties (discretionary, when budget allows)
How we credit you:
- Name (or handle) in advisory
- Link to your website/Twitter (if provided)
- Description of vulnerability found
If you prefer anonymity, just let us knowโwe respect that.
Transparency โ
When a vulnerability is fixed, we will:
- Publish a security advisory with:
- Description of vulnerability
- Impact and severity
- Affected versions
- Credit to researcher
- Remediation steps for users
- Notify affected users (if applicable)
- Update our security documentation
Safe Harbor โ
Lantern commits to not pursuing legal action against security researchers who:
โ Follow responsible disclosure:
- Report vulnerabilities privately
- Give us reasonable time to fix (30-90 days)
- Don't actively exploit vulnerabilities on production
โ Act in good faith:
- Make a good faith effort to avoid privacy violations
- Don't access more data than necessary to demonstrate the issue
- Don't intentionally harm users or degrade service
- Don't demand payment or rewards as a condition of disclosure
โ Stay within scope:
- Test only on accounts you control
- Don't exfiltrate user data
- Don't test on production systems without permission
If you're unsure whether your testing would violate this policy, please ask first.
Security Research Guidelines โ
Do's โ โ
- Do test on your own accounts
- Do use our development environment (
dev.ourlantern.app) when possible - Do document your findings thoroughly
- Do suggest fixes or mitigations
- Do ask questions if unsure about scope
- Do report even if you're not sure it's exploitable
Don'ts โ โ
- Don't access or modify other users' data
- Don't perform load testing or DDoS attacks
- Don't use automated scanners without prior approval
- Don't publicly disclose before we've patched
- Don't leverage vulnerabilities for personal gain
- Don't spam or harass our systems
Severity Guidelines โ
We use CVSS v3.1 for severity scoring, but here's a simplified guide:
Critical (9.0-10.0) โ
- Remote code execution
- Authentication bypass affecting all users
- Encryption key exposure
- Mass data breach
Response: Emergency patch within 24-48 hours
High (7.0-8.9) โ
- Authentication bypass affecting some users
- SQL injection or NoSQL injection
- Privilege escalation
- Sensitive data exposure (PII)
Response: Patch within 7 days
Medium (4.0-6.9) โ
- CSRF on sensitive actions
- Information disclosure (non-PII)
- Authorization flaws
- Insecure defaults
Response: Patch within 30 days
Low (0.1-3.9) โ
- Missing security headers
- Cookie security issues
- UI/UX security improvements
- Rate limiting gaps
Response: Patch within 90 days
Bounty Program (Future) โ
Current Status โ
โณ Not yet active - We're a small team with limited budget.
When We'll Start โ
We plan to launch a formal bug bounty program when:
- We have raised funding or reached profitability
- We've completed an external security audit
- We have dedicated security engineering resources
What to Expect โ
When active, bounties will likely be:
- Critical: $500-$2,000
- High: $200-$500
- Medium: $50-$200
- Low: Swag + recognition
For now: We offer recognition, credit, and our deep gratitude. ๐
Example Reports (Anonymized) โ
Good Report โ โ
Title: Stored XSS in Lantern Name Field
Description:
The Lantern Name field does not properly sanitize user input,
allowing an attacker to inject JavaScript that executes when
other users view the profile.
Impact:
An attacker could steal session tokens, perform actions on
behalf of victims, or redirect users to phishing sites.
Steps to Reproduce:
1. Create account
2. Set Lantern Name to: <script>alert(document.cookie)</script>
3. Have another user view your profile
4. JavaScript executes in victim's browser
Suggested Fix:
Sanitize all user input with DOMPurify before rendering.
Specifically, see UserProfile.jsx line 42.
Severity: High (CVSS 7.5)Poor Report โ โ
Title: Security vulnerability
Description:
Your site has a bug.
Steps:
Just look at the code.
Impact:
Bad.Why it's poor: No details, no reproduction steps, no impact assessment.
FAQs โ
Q: Can I test on production? โ
A: Only on accounts you control. Don't access other users' data or disrupt service.
Q: What if I found something but I'm not sure it's a vulnerability? โ
A: Report it anyway! We'd rather triage a non-issue than miss a real vulnerability.
Q: Can I automate testing? โ
A: Ask first. Automated scanners can disrupt service. We may provide a test environment.
Q: Will you fix all reported issues? โ
A: We'll fix all valid security issues. We may deprioritize low-severity issues or accept certain risks with documentation.
Q: Can I publish a blog post about my findings? โ
A: Yes, after we've deployed a fix and coordinated disclosure timeline. We encourage public research!
Q: What if we disagree on severity? โ
A: We'll discuss it transparently. We use CVSS scoring and industry standards, but we're open to debate.
Community Security Ethos โ
We Believe In โ
โ
Security by design - Build it right from the start
โ
Defense in depth - Multiple layers of protection
โ
Least privilege - Minimal access, minimal data
โ
Transparency - Open about our approach and limitations
โ
Collaboration - Security is a team sport
We're Open To โ
๐ก Architecture feedback - "Have you considered...?"
๐ก Best practice suggestions - "Industry standard is..."
๐ก Threat modeling - "What if an attacker...?"
๐ก Alternative approaches - "Signal does it this way..."
We're not perfect. We're a small team doing our best. If you see something that could be better, please tell us. We're listening.
Contact โ
Primary: security@ourlantern.app (coming soon)
Backup: GitHub Issues (public, non-sensitive only)
PGP Key: Available on request
Response time: We aim for 48 hours, but we're a small team. If urgent, mark it as such.
Updates to This Policy โ
We'll update this policy as we grow. Major changes will be:
- Announced to researchers who've previously reported
- Posted on our blog/website
- Versioned in our GitHub repository
Last major update: January 4, 2026 - Initial comprehensive policy
Thank you for helping us keep Lantern secure! ๐
Together, we can build something trustworthy.