1. Reporting Vulnerabilities
2. Scope
3. Security Features
4. Security Checklist
5. Monitoring & Response

We take security, accuracy, and integrity very seriously.

If you discover a security vulnerability or any critical issue that could compromise:

• User data
• Website stability
• Information authenticity
• Third-party copyrights

Please report it confidentially instead of publicly disclosing it.

• Email: m.maspero at umcutrecht.nl
• Alternatively, open a private GitHub Security Advisory if available for this repository.

Please include:

• A clear description of the vulnerability
• Steps to reproduce (if applicable)
• Any suggested fixes or mitigation ideas

We will respond within 5 business days and aim to resolve any verified security issues promptly.

This project consists mainly of public, factual information.

Security reports are in-scope if they involve:

• Unauthorized access or modification of the repository
• Malicious code or dependency vulnerabilities
• Leakage of confidential contributor information
• Data integrity risks (e.g., tampering of commercial product descriptions)
• Misinformation that could lead to clinical safety risks

The following are not considered security vulnerabilities:

• Typos, broken links, or formatting issues
• Disagreements over interpretation of technical data
• Lack of endorsements or certifications from manufacturers

(These can be reported via regular GitHub Issues.)

• Contact Form: 3 attempts per 5 minutes
• Newsletter Signup: Protected via database constraints
• Analytics: Graceful handling of duplicate visitor tracking

• Strict CSP headers prevent XSS attacks
• Only allows trusted sources for scripts and styles
• Blocks inline scripts and unsafe eval

• Strict-Transport-Security: Forces HTTPS connections
• X-Content-Type-Options: Prevents MIME type sniffing
• X-Frame-Options: Prevents clickjacking
• X-XSS-Protection: Browser XSS protection
• Referrer-Policy: Controls referrer information

• All forms use Zod schema validation
• Server-side validation in edge functions
• Sanitized database queries via Supabase client

• Row Level Security (RLS) enabled on all tables
• Public access policies only where necessary
• Proper unique constraints to prevent duplicates

• Row Level Security (RLS) enforced on all database tables
• Role-based route protection (Admin, Reviewer, Company)
• Four user roles: User, Reviewer, Company Representative, Administrator
• Automatic admin bypass for company certifications
• Maximum 5 verified representatives per company
• Activity logging for company representative actions
• Audit logs for admin actions and role changes

Database views use security_invoker = on to ensure RLS policies are respected:

• reviews_with_github_tracking - Reviewer assignment data
• analytics_summary - Platform analytics
• company_products - Company product relationships
• analytics_public - Restricted to authenticated users only

This prevents RLS bypass attacks where views could expose data from underlying tables.

• IP Addresses: All IP addresses are hashed using SHA-256 before storage
• Columns: ip_hash used consistently across:
  • mfa_activity_log
  • consent_audit_log
  • security_events
  • profile_document_access_log
• Data Export: User data exports redact IP hashes and user agents

Users can export their data via Profile → Data Export:

• Profile information
• Role assignments
• Review history
• MFA activity (sanitized - no IP addresses or user agents)
• GDPR privacy notice included in export files

• Analytics tracking only activates with explicit consent
• Consent stored with version and timestamp in consent_audit_log
• isTrackingAllowed() gate on all tracking operations
• clearTrackingIds() for consent withdrawal

• All external links use rel="noopener noreferrer" when target="_blank"
• User input is validated and sanitized (search, filters, forms)
• Dependencies are regularly audited (see CI)
• No secrets or credentials are committed to the repo
• Data files are checked for consistency and correctness
• Error boundaries are used for critical UI components
• All forms use proper CSRF and XSS protections
• Security policy is documented and up to date
• Database views use security_invoker for RLS enforcement
• IP addresses hashed before storage (GDPR compliance)

The system logs the following security events:

• Failed form submissions
• Rate limit violations
• Unusual activity patterns

1. Rate Limit Exceeded: Automatic temporary blocking
2. Failed Submissions: Logged with security context
3. Database Errors: Graceful degradation with logging

Weekly Tasks:

• Review security logs
• Check for failed authentication attempts
• Monitor database performance

Monthly Tasks:

• Review and update security policies
• Test incident response procedures
• Update security documentation

• Automatic cleanup of analytics data older than 1 year
• Regular monitoring of constraint violations
• Proper error handling for duplicate entries

• Cookie consent management
• User data deletion capabilities
• Transparent data collection practices

We practice coordinated disclosure:

• We will acknowledge receipt of your report
• We will work privately with you to understand and resolve the issue
• We will publicly disclose security incidents only after a fix is available
• You will be credited for responsible disclosure if desired

We greatly appreciate your help in making this project safe, reliable, and trustworthy for the entire radiotherapy community.

Last Updated: February 2, 2026