If you discover a security vulnerability in JobSentinel, please report it responsibly.

DO NOT open a public GitHub issue for security vulnerabilities.

Instead, use the private security contact listed for the project. If you use GitHub, private vulnerability reporting also works.

When reporting a vulnerability, please include:

1. Description of the vulnerability
2. What you did before it happened
3. Potential impact
4. Any suggested fixes (optional but appreciated)

• Acknowledgment: Within 48 hours
• Initial assessment: Within 1 week
• Fix timeline: Depends on severity, typically 1-4 weeks

JobSentinel is built with privacy and security as core principles:

• Zero telemetry: JobSentinel does not collect analytics or send data to JobSentinel servers.
• Local-first: Job-search records are stored on the user's device by default. External channels send only configured or approved details.
• No account required: Core workflows work without a JobSentinel account.
• User-controlled network use: Job checks, location detection, configured alerts, and optional external AI can use network access only through visible user-controlled features.

• OS-native keyring: Credentials stored using Windows Credential Manager, macOS Keychain, or Linux Secret Service
• No plaintext credential storage: New notification links, access codes, and passwords should use the OS credential manager. Job-search data is stored in the local SQLite database, and settings backups can include private search choices.
• Minimal retention: Only stores what's necessary for configured features

• HTTPS-first external paths: Webhooks, location lookup, provider calls, configured secrets, and job-page import fetches use HTTPS. Saved public job links may be http or https only when validation confirms a public host and blocks local, private, and userinfo targets.
• User-controlled webhooks: Notifications only sent to user-configured endpoints

• Memory safety: Rust denies unsafe code by default. Windows platform FFI uses scoped unsafe code where OS APIs require it.
• SQL injection prevention: All database queries use SQLx parameterized queries
• Input validation: User input validated before use
• Dependency auditing: Regular cargo audit checks

• DOMPurify sanitization: All user-generated HTML (Resume Builder) sanitized before rendering
• No dangerouslySetInnerHTML without sanitization: React components use safe rendering
• Script tag blocking: All XSS vectors (scripts, event handlers, JavaScript URLs) removed
• Documentation: See XSS Prevention Guide

• Proper URL parsing: Uses url crate to parse URLs instead of string prefix matching
• Webhook validation: Slack, Discord, and Teams webhooks validated for correct host and path
• No bypass attacks: Query parameter, subdomain, and fragment bypass attempts blocked
• Documentation: See URL Validation Security

• Path canonicalization: All file paths canonicalized to prevent traversal attacks
• No shell invocation: Commands executed directly without shell interpretation
• Controlled temp directories: UUID-named temp directories prevent race conditions
• Output validation: Generated files validated to stay within controlled directories
• Documentation: See Command Execution Security

• HTTPS-only: All webhook URLs must use HTTPS
• Domain allowlisting: Only known webhook providers (Slack, Discord, Teams) allowed
• Path validation: Webhook paths verified for correct structure
• Encrypted local vault: Webhook URLs stored as AEAD-encrypted vault rows, with keys protected by OS credential storage or optional passphrase lock
• Documentation: See Webhook Security Guide

Detailed security documentation is available in the docs/security/ directory:

• Secret Vault And Keychain Integration - SQLCipher storage, encrypted vault rows, OS key protection, and passphrase wrapping
• XSS Prevention - Cross-site scripting protection with DOMPurify
• URL Validation - Proper URL parsing vs string prefix matching
• Command Execution Security - OCR and external tool security
• Webhook Security - Slack, Discord, and Teams webhook validation

• DOMPurify Test Examples - XSS sanitization test cases

Security fixes are released as patch versions (e.g., 2.5.1) and announced in the CHANGELOG. We recommend always running the latest version.