Security Policy

1. Responsible Disclosure Policy

Irreva operates a responsible disclosure program. We believe that independent security researchers and the broader community play an important role in keeping the web safer for everyone. If you have identified a vulnerability in Irreva's website, infrastructure, client-side tools, or API routes, we want to hear from you before it becomes a public problem.

Responsible disclosure means giving us the opportunity to investigate and fix an issue before it is publicly disclosed. In return, we commit to treating all good-faith reports with respect and transparency. Specifically, when you report a vulnerability in compliance with this policy, we commit to:

• Acknowledge receipt of your report within 3 business days
• Provide an initial severity assessment and triage response within 7 business days
• Keep you informed of our progress at each stage of the investigation and fix
• Notify you promptly when the vulnerability has been resolved and deployed
• Not pursue legal action against researchers who act in accordance with this policy
• Publicly credit you for your discovery — with your name, handle, or alias — if you wish and if you consent
• Treat your personal information in accordance with our Privacy Policy

We do not currently operate a paid bug bounty program. We may introduce one in the future. Recognition, credit, and our genuine appreciation are what we can offer today.

2. How to Report a Vulnerability

Please send all security disclosures directly to our security team by email. Do not open a public GitHub issue, post to social media, or discuss the vulnerability in any public forum before coordinating with us.

To help us triage and resolve your report as efficiently as possible, please include as many of the following details as you can:

• Description: A clear, concise description of the vulnerability and the type of issue (e.g., XSS, CSRF, open redirect, information disclosure)
• Impact: Your assessment of the potential security impact, including which users or data could be affected
• Steps to reproduce: Detailed, step-by-step reproduction instructions, including relevant URLs, HTTP requests, payloads, or configuration details
• Proof of concept: Screenshots, a screen recording, or a minimal code snippet demonstrating the issue — where it is safe and responsible to do so
• Environment: Browser name and version, operating system, and the specific Irreva page or tool involved
• Suggested fix: If you have a suggested remediation, we welcome it — though it is entirely optional

If you believe the vulnerability is critical, involves live user data, or could cause immediate harm if known publicly, please mark your email subject line [CONFIDENTIAL SECURITY REPORT] and we will treat it with the highest priority and confidentiality.

3. Scope

The following assets and vulnerability classes are in scope for security reports submitted under this policy:

• The Irreva website at irreva.com and all subdomains
• Client-side JavaScript and WebAssembly tool implementations — including Cross-Site Scripting (XSS), prototype pollution, and DOM-based injection
• Content Security Policy (CSP) bypasses that allow script execution
• Subdomain takeover vulnerabilities on any irreva.com subdomain
• Open redirects that could be exploited for phishing or credential theft
• Sensitive information disclosure in JavaScript source bundles, API responses, HTTP headers, or error messages
• Cross-Site Request Forgery (CSRF) on any state-changing server endpoints
• Server-Side Request Forgery (SSRF) through any API routes
• Injection vulnerabilities (command injection, header injection) in server-side API routes
• Authentication or authorisation flaws in any future authenticated features
• Dependency vulnerabilities in actively used packages that have direct, practical exploitability in our deployment

The following are out of scope and reports in these categories will not be acted upon:

• Theoretical or speculative vulnerabilities without a working proof of concept demonstrating real impact
• Denial of service (DoS or DDoS) attacks, resource exhaustion, or availability disruption
• Social engineering, phishing, or vishing attacks targeting Irreva staff or contractors
• Physical security issues at any facility
• Attacks that require the victim to have already installed malware or be in a compromised environment
• Automated scanner output that has not been manually triaged and validated
• Missing security headers (e.g., X-Content-Type-Options, Referrer-Policy) that do not lead to a demonstrable attack chain
• Self-XSS or issues that only affect the researcher's own browser session and cannot be exploited against other users
• Rate limiting on non-sensitive public endpoints
• Brute force attacks on public tools that have no authentication
• Third-party services including Vercel, Google Analytics, and Google AdSense — please report these directly to the respective vendors
• Clickjacking on pages with no sensitive actions

4. Disclosure Timeline

We operate on a coordinated disclosure model. The following table outlines our target response timeframes from the moment a report is received:

We request a 90-day embargo from the date of initial report before any public disclosure. This gives us adequate time to investigate, develop a fix, test it, and deploy it to production. If for any reason we cannot resolve the issue within 90 days, we will proactively communicate this to you and negotiate an extended timeline or agree on a partial disclosure approach that does not put users at risk.

We will not ask you to extend the embargo indefinitely. If 90 days have passed and we have not provided a satisfactory resolution or communication, you are free to disclose the vulnerability publicly.

5. Good-Faith Research Guidelines

To qualify for the protections and commitments described in this policy, your security research must comply with the following rules. Violation of any of these rules removes you from the protections offered by this policy, regardless of the merit of your finding:

• Only test accounts, data, and systems that you own or that you have explicit written authorisation to access
• Do not exploit a vulnerability beyond the minimum necessary to demonstrate its existence and impact
• Do not access, copy, modify, delete, or exfiltrate any user data, even as a proof of concept
• Do not disrupt Irreva's service availability, degrade performance, or negatively impact other users in any way
• Do not conduct automated scanning at a rate or volume that could constitute a denial-of-service attack against the platform
• Do not publicly disclose the vulnerability — including on social media, GitHub, forums, or any public channel — until we have had a reasonable opportunity to fix it and have agreed on a disclosure timeline with you
• Comply with all applicable laws in your jurisdiction throughout your research activities

Researchers who comply with these guidelines in good faith will not face legal action from Irreva for the security research itself. We explicitly commit not to pursue or support any legal claim for technical circumvention of access controls where the research was conducted in strict accordance with this policy.

6. Architecture Security Notes

Understanding Irreva's technical architecture can help security researchers focus their efforts on the most relevant attack surfaces and avoid wasting time on areas that are architecturally out of scope:

• Client-side processing only: All file and data processing — image compression, PDF manipulation, OCR, format conversion, AI inference — runs entirely in the user's browser via JavaScript and WebAssembly. No files are transmitted to or stored on Irreva's servers at any point. Server-side file injection or data exfiltration through tool inputs is architecturally impossible by design.
• No user accounts: Irreva has no user authentication system, no login page, no persistent user profiles, and no password management. There are no session tokens, credentials, or account data to compromise.
• No user-facing database: Irreva does not operate a relational or document database containing user data. There is no SQL injection surface for user information.
• Hosted on Vercel: The Irreva platform runs on Vercel's global edge infrastructure. Infrastructure-level security — including server hardening, network isolation, and CDN security — is managed by Vercel. Vulnerabilities in Vercel's infrastructure should be reported directly to Vercel.
• API routes: A limited number of server-side Next.js API routes handle specific features, including contact form submission, currency rate fetching, and IP geolocation. These routes represent the primary server-side attack surface and are in scope for this program.
• Third-party scripts: Google Analytics 4 and Google AdSense scripts run on the frontend, consent-gated via Google Consent Mode v2. Vulnerabilities in these third-party scripts should be reported to Google, not to Irreva.

7. Privacy of Security Reporters

When you submit a security report, you may share personal information including your name, email address, and technical details. We will use this information solely to investigate and respond to your report. We will not share your identity publicly without your explicit consent. If you request anonymity, we will honour that request and will not disclose your identity in any public acknowledgement.

Your report and associated personal data will be handled in accordance with our Privacy Policy. Security reports are retained for as long as necessary to support the remediation process and any subsequent internal review.

8. Contact

For all security disclosures, please contact the Irreva security team directly. Do not use the general contact form for security reports, as it is not monitored with the same priority as the dedicated security inbox.

For general enquiries unrelated to security vulnerabilities — such as questions about our privacy practices, data handling, or tool functionality — please use our contact page or review our Privacy Policy.