The table below lists all security measures active in QRDoc and their current status:
| Control | Description | Status |
|---|---|---|
| Content Security Policy (CSP) | Restricts resource origins; blocks framing; blocks external connections | Active |
| Subresource Integrity (SRI) | SHA-512 hash verification on the QRCode.js CDN script | Active |
| HTTPS Enforcement | JavaScript redirect to HTTPS if loaded over HTTP (non-localhost) | Active |
| X-Frame-Options: DENY | Prevents the page from being embedded in iframes (clickjacking) | Active |
| X-Content-Type-Options: nosniff | Prevents MIME-type sniffing attacks | Active |
| Referrer Policy | Set to strict-origin-when-cross-origin to limit URL leakage |
Active |
| Client-side Rate Limiting | Maximum 3 QR generations per 60-second window, enforced in JavaScript | Active |
| Input Sanitisation | All URLs trimmed and capped at 2048 characters before processing | Active |
| URL Validation | Protocol check (HTTPS only), hostname allowlist, path-pattern regex per platform | Active |
| XSS Prevention | All user-supplied content rendered via textContent, never innerHTML |
Active |
| Sensitive Data Clearance | URL fields wiped from memory on tab close (beforeunload) |
Active |
| Security Event Logging | Key events (platform select, rate limit, QR generate) logged to browser console | Console only |
| CSP unsafe-inline in script-src | Inline scripts permitted โ weakens XSS protection (known limitation) | Known gap |
QRDoc enforces the following CSP via an HTTP-equivalent <meta> tag:
Key directives and their purpose:
script-src includes 'unsafe-inline' because the application logic is written as inline scripts. This means a Content Security Policy alone cannot prevent injected inline scripts from running. The XSS risk is mitigated by textContent-only rendering and strict URL validation, but upgrading to hash-based CSP is recommended for future versions.
The only external resource loaded by QRDoc โ the QRCode.js library from cdnjs.cloudflare.com โ is protected with an SRI hash. Your browser will refuse to execute the script if it has been modified in transit or on the CDN.
Every URL submitted to QRDoc passes through a multi-layer validation pipeline before any processing occurs:
URL constructor, which normalises and rejects malformed input.https: URLs are accepted. HTTP, data URIs, and javascript: URIs are rejected.To prevent automated abuse, QRDoc enforces a client-side rate limit of 3 QR code generations per 60-second window. If the limit is exceeded, the generate button is disabled and a warning is shown.
Rate limit state is stored in a JavaScript Map in browser memory and is reset when the tab is closed or the page is refreshed. It does not persist across sessions.
If you discover a security vulnerability in QRDoc, please report it responsibly before public disclosure. We take all reports seriously and will respond promptly.
Contact Ashwinkumar D Basari directly via LinkedIn or the contact details on the About page. Please include a description of the vulnerability, steps to reproduce it, and the potential impact. We will acknowledge your report within 72 hours and aim to release a fix within 14 days for critical issues.