IMPORTANT: Do NOT open public GitHub issues for security vulnerabilities.

• Email: security@richertunes.com (or xfear26@hotmail.com)
• Response Time: Within 48 hours
• Expected Resolution: Based on severity (Critical: 7 days, High: 30 days)

• ✅ CodeQL Static Analysis: Automated C# security scanning
• ✅ Secret Scanning: GitLeaks monitors for Tidal credentials
• ✅ Dependency Monitoring: Dependabot automated updates
• ✅ Vulnerability Scanning: NuGet package vulnerability detection
• ✅ Security Policy: Documented disclosure process

• Container image scanning (when Docker images published)
• SBOM generation for releases
• Artifact signing with Cosign/GPG
• Third-party penetration testing
• Bug bounty program (future)

Tidalarr embeds a small set of well-known, public TIDAL protocol constants required for the plugin to interoperate with the TIDAL API:

• The TIDAL OAuth client identifiers (CLIENT_ID, CLIENT_ID_PKCE, CLIENT_SECRET_PKCE) — the same fixed values shipped in TIDAL's official clients and used by every interoperable TIDAL tool (e.g. TidalSharp).
• The shared stream master key used by TIDAL's playback format.

These are not private secrets and not user credentials — they are fixed, publicly-known, reverse-engineered protocol values present in plain text across many open-source TIDAL projects. They cannot be meaningfully hidden (any client able to use them can also reveal them), so they are intentionally allowlisted in .gitleaks.toml to avoid false positives while genuine secrets in the same files are still detected.

Your private credentials — your TIDAL OAuth tokens / session — are never committed: they live only in local plugin configuration (pkce_state.json + token storage), are encrypted at rest via Lidarr.Plugin.Common, and are gitignored.

Security team acknowledges receipt within 48 hours

• Critical (CVSS 9.0-10.0): Immediate action, 7-day resolution
• High (CVSS 7.0-8.9): Priority fix, 30-day resolution
• Medium (CVSS 4.0-6.9): Standard fix, 90-day resolution
• Low (CVSS 0.1-3.9): Routine fix, next release

• Private security branch created
• Patch developed and tested
• Backports to supported versions
• Security advisory drafted

• 90-day disclosure timeline (negotiable)
• Security advisory published
• CVE assigned if applicable
• Users notified via releases and security tab

• Lessons learned documented
• Prevention measures implemented
• Security audit updated
• Contributor acknowledged (with permission)

• All external data must be validated: User input, API responses, file contents
• Whitelist approach: Define what's allowed, reject everything else
• Type validation: Ensure data types match expectations

• No hardcoded secrets: Use environment variables or encrypted storage
• Tidal credentials: OAuth tokens in secure configuration only
• OAuth tokens: Encrypt at rest using Lidarr.Plugin.Common token storage
• Session management: Implement proper expiration and refresh logic

• SQL Injection: Use parameterized queries (N/A - no SQL database)
• Command Injection: Sanitize all shell command inputs
• Path Traversal: Validate and sanitize file paths before access
• XSS: Encode output for any web-facing components

• No sensitive data in errors: Strip credentials, paths, internal state
• User-friendly messages: Generic errors to users, detailed logs internally
• Fail securely: Default to denying access on errors

• Monitor Dependabot PRs weekly
• Review security advisories for dependencies
• Test updates in isolation before merging
• Document breaking changes

• Minimize dependency count
• Prefer well-maintained packages
• Review transitive dependencies
• Use lock files for reproducibility

Current vulnerable packages (example - update regularly):

• [To be populated by security scans]

• OAuth 2.0 + PKCE flow implementation
• Token refresh before expiration
• Secure token storage (encrypted at rest)
• Never log tokens or credentials

• Respect Tidal API rate limits
• Implement backoff on 429 responses
• Cache responses to reduce API calls
• Monitor API usage patterns

• Validate all API responses
• Handle malformed data gracefully
• Sanitize metadata before storage
• Verify file checksums for downloads

• Verify HTTPS for all Tidal connections
• Validate content types and file sizes
• Check file integrity (checksums)
• Scan for malicious content (optional)

• Secure cleanup of temporary downloads
• No credentials in temp files
• Appropriate file permissions
• Automatic cleanup on failure

• Never log credentials, tokens, or PII
• Sanitize paths and file names
• Redact sensitive fields in structured logs
• Secure log file permissions

1. User credentials: Tidal account credentials, OAuth tokens
2. Application data: Downloaded music, metadata cache, search history
3. Configuration: Plugin settings, API credentials, quality preferences
4. System access: File system access, network access, Lidarr integration

• Attack vector: Exposed tokens, weak encryption, logging
• Impact: Unauthorized Tidal account access
• Mitigation: Encrypted storage, no logging, secure transmission

• Attack vector: Rate limit violations, quota exhaustion
• Impact: Account suspension, service degradation
• Mitigation: Rate limiting, caching, backoff strategies

• Attack vector: Modified downloads, corrupted metadata
• Impact: Malicious files, incorrect tagging
• Mitigation: Checksum validation, HTTPS enforcement

• Attack vector: Compromised dependencies, malicious packages
• Impact: Code execution, data exfiltration
• Mitigation: Dependency scanning, subresource integrity, code review

• Attack vector: Malicious file paths in downloads
• Impact: Write to unauthorized locations
• Mitigation: Path sanitization, permission checks

External:

• Tidal API endpoints
• NuGet package sources
• GitHub Actions workflows
• Docker base images (future)

Internal:

• Lidarr plugin interface
• File system operations
• Network requests
• Configuration storage

• Minimal data collection: Only what's needed for functionality
• No telemetry: No usage analytics or tracking
• User control: Users manage their own credentials
• Third-party data: Only Tidal API, no other services

• OpenSSF Best Practices: Following badge criteria
• CWE Top 25: Addressing common weaknesses
• OWASP Top 10: Preventing web vulnerabilities

• MIT License
• Compatible dependency licenses
• No GPL/AGPL dependencies (Dependabot blocks these)

• Email: xfear26@hotmail.com
• GitHub: @RicherTunes

• Open to community security researchers
• Coordinated disclosure welcomed
• Acknowledgments in SECURITY.md

We appreciate security researchers who responsibly disclose vulnerabilities. Contributors will be acknowledged here with permission:

• [Your name here for responsible disclosure]

• Tidal Developer Documentation
• Lidarr Security Guidelines
• Lidarr.Plugin.Common Security
• OWASP Secure Coding Practices
• CWE/SANS Top 25

Last Updated: 2026-03-10 Version: 1.0 Maintained By: RicherTunes