Currently, we support security updates for the following versions:
| Version | Supported |
|---|---|
| 0.1.x | ✅ |
| < 0.1 | ❌ |
We take the security of @photostructure/sqlite seriously. If you believe you have found a security vulnerability, please report it to us as described below.
Please do not report security vulnerabilities through public GitHub issues.
Instead, please report them via one of the following methods:
- Email us at security@photostructure.com
- Use GitHub's private vulnerability reporting feature (if available)
Please include the following information in your report:
- Type of issue (e.g., buffer overflow, SQL injection, cross-site scripting, etc.)
- Full paths of source file(s) related to the manifestation of the issue
- The location of the affected source code (tag/branch/commit or direct URL)
- Any special configuration required to reproduce the issue
- Step-by-step instructions to reproduce the issue
- Proof-of-concept or exploit code (if possible)
- Impact of the issue, including how an attacker might exploit it
- We will acknowledge receipt of your vulnerability report within 48 hours
- We will provide a more detailed response within 7 days
- We will work on fixes and coordinate disclosure timeline with you
This project employs multiple layers of automated security scanning:
- npm audit - Scans for known vulnerabilities in dependencies
- OSV Scanner - Google's Open Source Vulnerabilities scanner
- CodeQL - GitHub's semantic code analysis for both JavaScript/TypeScript and C++
- TruffleHog - Secrets detection in code
- ESLint Security Plugin - Static analysis for JavaScript/TypeScript security patterns
Our CodeQL setup is configured to focus on security issues in our own code:
- JavaScript/TypeScript: Uses
paths-ignoreto exclude upstream and vendor directories - C++: Uses SARIF filtering to exclude upstream SQLite code after scanning
This ensures we identify security issues in our code while filtering out alerts from upstream dependencies that we cannot directly control.
These scans run automatically on:
- Every push to the main branch
- Every pull request
- Weekly scheduled scans
- Manual workflow dispatch
- All dependencies are regularly updated via Dependabot
- Security patches are prioritized and released quickly
- Native C++ code is analyzed with clang-tidy and ASAN
- Memory safety is validated through comprehensive testing
Since this package includes native C++ bindings to SQLite:
- We use the official SQLite amalgamation source
- SQLite is compiled with recommended security flags
- Buffer overflows are prevented through careful memory management
- All user inputs are properly validated before passing to SQLite
The following SQLite security features are available:
// Restrict file access to read-only
const db = new DatabaseSync("database.db", {
readonly: true,
});
// Disable extension loading by default
// Extensions must be explicitly enabled
db.allowExtension(); // Required first
db.enableLoadExtension(true); // Then enable
db.loadExtension("path/to/extension");- Always validate and sanitize user input before using in SQL queries
- Use parameterized queries to prevent SQL injection
- Run with minimal permissions when possible
- Keep dependencies updated regularly
- Monitor security advisories for SQLite and Node.js
When we receive a security report, we will:
- Confirm the problem and determine affected versions
- Audit code to find similar problems
- Prepare fixes for all supported versions
- Coordinate disclosure with the reporter
We aim to disclose vulnerabilities responsibly, balancing the need for users to be informed with giving them time to update.