The Finch framework team takes the security of our software seriously. We appreciate your efforts to responsibly disclose any security vulnerabilities you find and will make every effort to acknowledge your contributions.
We provide security updates for the following versions of Finch:
| Version | Supported | Status |
|---|---|---|
| 1.x.x | ✅ | Active support |
| 0.9.x | ✅ | Security fixes only |
| 0.8.x | Limited support | |
| < 0.8 | ❌ | No longer supported |
Note: We strongly recommend always using the latest stable version to ensure you have all security patches and improvements.
Please do not report security vulnerabilities through public GitHub issues, discussions, or pull requests.
If you discover a security vulnerability, please report it privately using one of these methods:
- Go to the Security tab of the Finch repository
- Click on "Report a vulnerability"
- Fill out the vulnerability details form
- Submit the report
Send an email to: [INSERT SECURITY EMAIL]
Use the subject line: [SECURITY] Brief description of the issue
For highly sensitive security issues, you can use PGP encryption:
- PGP Key: [INSERT PGP KEY FINGERPRINT]
- Public Key: Available at [INSERT KEY LOCATION]
To help us understand and resolve the issue quickly, please include as much of the following information as possible:
- Type of vulnerability (e.g., SQL injection, XSS, authentication bypass, etc.)
- Full paths of source file(s) related to the vulnerability
- Location of the affected source code (tag/branch/commit or direct URL)
- Step-by-step instructions to reproduce the issue
- Proof-of-concept or exploit code (if possible)
- Impact assessment - What could an attacker accomplish?
- Affected versions - Which versions of Finch are impacted?
- Suggested fix (if you have one)
- Your name and contact information for follow-up questions
## Vulnerability Summary
Brief description of the vulnerability
## Vulnerability Type
[ ] SQL Injection
[ ] Cross-Site Scripting (XSS)
[ ] Authentication/Authorization Issues
[ ] Server-Side Request Forgery (SSRF)
[ ] Path Traversal
[ ] Remote Code Execution
[ ] Denial of Service
[ ] Information Disclosure
[ ] Other: ___________
## Affected Component
Specify the module, file, or function affected
## Affected Versions
Which versions are impacted?
## Severity Assessment
[ ] Critical - Can be exploited remotely with no authentication
[ ] High - Significant impact, requires some user interaction
[ ] Medium - Limited impact or difficult to exploit
[ ] Low - Minimal impact
## Steps to Reproduce
1. Step 1
2. Step 2
3. Step 3
## Proof of Concept
Provide code or detailed explanation
## Impact
Describe what an attacker could accomplish
## Suggested Remediation
If you have suggestions for fixing the issue
## Additional Information
Any other relevant detailsWe are committed to responding to security reports in a timely manner:
| Timeline | Action |
|---|---|
| Within 48 hours | Acknowledge receipt of your vulnerability report |
| Within 7 days | Provide an initial assessment and expected timeline |
| Within 30 days | Provide a detailed response with either a fix timeline or explanation |
| Within 90 days | Aim to release a fix (depending on complexity) |
- Acknowledgment: We'll confirm receipt of your report within 48 hours
- Assessment: We'll investigate and assess the severity and impact
- Communication: We'll keep you updated on our progress
- Fix Development: We'll work on a patch or mitigation
- Disclosure: We'll coordinate with you on the public disclosure timeline
- Credit: With your permission, we'll acknowledge your contribution
We follow a coordinated disclosure process:
- Private Development: Security fixes are developed in private
- Vendor Notification: We notify affected parties before public release
- Fix Release: We release the security patch
- Public Disclosure: We publish a security advisory
- Credit: We credit the reporter (unless they prefer to remain anonymous)
- Standard Timeline: 90 days from initial report to public disclosure
- Active Exploitation: Expedited timeline if the vulnerability is being actively exploited
- Complex Issues: Extended timeline for particularly complex vulnerabilities (with mutual agreement)
- We will not pursue legal action against security researchers who:
- Act in good faith
- Follow this disclosure policy
- Don't access data beyond what's necessary to demonstrate the vulnerability
- Don't intentionally harm our users or degrade service
- Don't publicly disclose the vulnerability before we've had a chance to fix it
Published security advisories can be found at:
- GitHub Security Advisories: https://github.com/uproid/finch/security/advisories
- Changelog: Security fixes are also documented in CHANGELOG.md
Subscribe to security notifications:
- Watch the repository on GitHub
- Select "Custom" → Check "Security alerts"
# Always use the latest stable version
dependencies:
finch: ^1.0.0 # Use caret for automatic minor/patch updatesRun regular updates:
dart pub upgrade// Never hardcode sensitive data
// ❌ Bad
final dbPassword = 'myPassword123';
// ✅ Good - Use environment variables
final dbPassword = Platform.environment['DB_PASSWORD'];// Always validate and sanitize user input
import 'package:finch/finch.dart';
class UserController extends Controller {
Future<Response> createUser(Request request) async {
// Validate input
final validator = Validator(request.body);
validator.rule('email', ['required', 'email']);
validator.rule('password', ['required', 'min:8']);
if (!validator.validate()) {
return Response.json({'errors': validator.errors}, 400);
}
// Process validated data
// ...
}
}// ✅ Use parameterized queries
final users = await db.query(
'SELECT * FROM users WHERE email = ?',
[email]
);
// ❌ Never concatenate user input
// final users = await db.query('SELECT * FROM users WHERE email = "$email"');// Use Finch's built-in authentication
import 'package:finch/finch.dart';
Route.group('/api', middleware: [AuthMiddleware()], children: [
Route.get('/profile', UserController.profile),
Route.post('/update', UserController.update),
]);// Always use HTTPS in production
final server = await HttpServer.bindSecure(
'localhost',
443,
SecurityContext()
..useCertificateChain('path/to/cert.pem')
..usePrivateKey('path/to/key.pem'),
);// Configure CORS properly
app.use(CorsMiddleware(
allowedOrigins: ['https://yourdomain.com'], // Don't use '*' in production
allowedMethods: ['GET', 'POST', 'PUT', 'DELETE'],
allowedHeaders: ['Content-Type', 'Authorization'],
allowCredentials: true,
));// Use secure session configuration
app.sessions(
secret: Platform.environment['SESSION_SECRET']!,
secure: true, // Only send over HTTPS
httpOnly: true, // Prevent JavaScript access
sameSite: 'strict', // CSRF protection
maxAge: Duration(hours: 24),
);// Implement rate limiting to prevent abuse
Route.group('/api', middleware: [
RateLimitMiddleware(maxRequests: 100, duration: Duration(minutes: 15))
], children: [
// Your routes
]);// Don't expose sensitive information in errors
try {
// Your code
} catch (e) {
// ❌ Bad - Exposes internal details
// return Response.json({'error': e.toString()}, 500);
// ✅ Good - Generic error message
logger.error(e); // Log internally
return Response.json({'error': 'An error occurred'}, 500);
}Before deploying your Finch application:
- All dependencies are up to date
- No hardcoded secrets in source code
- Environment variables are properly secured
- HTTPS/TLS is configured
- Input validation is implemented
- Parameterized queries are used for database operations
- Authentication and authorization are properly configured
- CORS is configured with specific origins (not
*) - Rate limiting is implemented
- Error messages don't expose sensitive information
- Security headers are configured (CSP, X-Frame-Options, etc.)
- File upload validation is implemented (if applicable)
- SQL injection protection is in place
- XSS prevention measures are implemented
- CSRF protection is enabled
- Logging is configured (but doesn't log sensitive data)
- Database Drivers: Security depends on the underlying database driver used
- Template Engine: User input in templates must be properly escaped
- File Uploads: Implement proper validation and storage practices
- WebSocket Security: Additional security measures needed for WebSocket connections
The Finch framework relies on various Dart packages. Security of these dependencies is monitored, but users should:
- Regularly run
dart pub outdatedto check for updates - Review security advisories for dependencies
- Use
dart pub auditwhen available
- Dart Analyzer: Run
dart analyzeto detect potential issues - Dependency Checker: Use
dart pub outdatedregularly - SAST Tools: Static Application Security Testing tools for Dart
- OWASP ZAP: For dynamic security testing
- OWASP Top 10
- Dart Security Guidelines
- CWE - Common Weakness Enumeration
- CVE - Common Vulnerabilities and Exposures
We appreciate the security researchers who have helped make Finch more secure:
- [To be added as vulnerabilities are responsibly disclosed]
Want to be listed here? Report a valid security vulnerability following our responsible disclosure policy.
For security-related questions that are not vulnerability reports:
- General Security Questions: Open a GitHub Discussion
- Security Team Email: [INSERT SECURITY EMAIL]
- Project Maintainers: See CONTRIBUTING.md
This security policy may be updated from time to time. Significant changes will be announced through:
- GitHub repository announcements
- Release notes
- Project communication channels
Last Updated: November 12, 2025
Version: 1.0
Thank you for helping keep Finch and its users safe! 🔒