Security at imisspdf

The shortest version: we eliminate most file-processing security risks by not having a file-processing server. Files are handled entirely inside your browser. The attack surface we still own (the website itself) is hardened with the standard set of HTTPS, security headers, dependency hygiene, and a responsible-disclosure path.

1. The architectural security argument

Most "is X PDF tool secure" questions fundamentally come down to: where is my file during processing? If the answer is "on a third party's server, even briefly", you inherit that party's security posture for that window — their key rotation, their access controls, their incident response, their subpoena policy.

imisspdf's answer is: the file is in your browser, in memory, only. It never traverses the public internet. The PDF library (pdf-lib + WebAssembly) is the same code that would run on a server, but it runs inside your browser tab on your device. The result: there is no server to compromise, no key to leak, no audit log to subpoena, no retention window to debate.

This is the same model used by 1Password's local processing, by Signal's E2E messaging, and by any "client-side encryption" SaaS — security follows from architecture, not just policy.

2. Transport security (the website itself)

• HTTPS-only. The site is served exclusively over HTTPS. HTTP requests are redirected.
• HSTS preload: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. Browsers refuse to fall back to HTTP for our domain.
• TLS 1.3 via Cloudflare's edge network, with modern cipher suites.
• HTTP/2 + HTTP/3 automatically.

3. Security headers

We set the standard set of defensive HTTP headers on every response (verifiable via curl -I https://imisspdf.com/):

• Strict-Transport-Security: max-age=31536000; includeSubDomains; preload — force HTTPS forever
• X-Content-Type-Options: nosniff — prevent MIME-type confusion attacks
• Referrer-Policy: strict-origin-when-cross-origin — minimise referrer leakage
• Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=() — deny access to sensitive browser APIs by default
• X-Frame-Options: SAMEORIGIN — prevent clickjacking via iframe embedding

You can test our headers at securityheaders.com for a third-party scorecard.

4. Dependency hygiene

imisspdf is built on a small set of open-source dependencies. The major ones:

• pdf-lib — pure-JS PDF processing
• pdfjs-dist — Mozilla's PDF rendering library
• signature_pad — drawn-signature canvas
• sortablejs — drag-to-reorder for page management
• Astro 5 — static site generator

We run automated dependency vulnerability scans (npm audit) on each build. We patch critical and high-severity CVEs within 7 days; we patch medium-severity within 30 days. We pin major versions to avoid surprise breakage from automatic updates.

5. Hosting and infrastructure

imisspdf is hosted on Cloudflare Pages:

• Static-site deployment — no application server, no database, no admin panel to compromise
• Cloudflare's edge network handles TLS termination, DDoS mitigation, WAF, and bot management
• Cloudflare Pages is SOC 2 Type 2 and ISO 27001 certified at the infrastructure level
• Deployment is via GitHub Actions with two-factor-authenticated maintainer access. No deploys land without commit attribution.

6. What data we hold (and don't)

• Your files: never received, never stored, never indexed. (Architecture, not policy — see the Privacy page.)
• Visit logs: standard Cloudflare access logs (IP, user agent, URL, timestamp), retained briefly for abuse detection and aggregate analytics
• Analytics: Google Analytics 4 with anonymised aggregation; opt-out via standard browser settings or extensions
• User accounts: we do not currently have user accounts. If we add them in the future, passwords would be salted + bcrypt-hashed and never logged in plaintext.

7. Incident response

If we discover a security incident affecting the site itself or any user-facing service:

• We will post a notice on the homepage within 24 hours of discovery
• We will email affected users (if any user accounts exist at the time) within 72 hours
• We will publish a post-incident write-up on the blog within 14 days, describing what happened, what data was affected (if any), and what we changed to prevent recurrence

Because we don't process user files server-side, the practical impact of any incident is bounded to the website itself (defacement, downtime) rather than file exposure.

8. Responsible disclosure / bug bounty

If you discover a security vulnerability in imisspdf, please report it privately so we can fix it before public disclosure:

We don't currently run a paid bug bounty program (we're early-stage), but we will increase the recognition and rewards as the project grows. We commit to never taking legal action against security researchers who follow this responsible-disclosure process in good faith.

In scope

• The website https://imisspdf.com and all its subpages
• The @imisspdf/pdf-utils npm package
• Source code in github.com/cakbeanie/imisspdf

Out of scope

• Cloudflare's own infrastructure (report to Cloudflare's HackerOne)
• Issues already known and publicly tracked
• Social engineering against our team
• Physical security of our offices
• Findings from automated scanners without a working proof-of-concept

9. Compliance posture

imisspdf is not yet certified under SOC 2 or ISO 27001 (those certifications take 6-12 months and meaningful audit costs that only make sense once we have substantial revenue). We commit to the same controls those frameworks require:

• Access controls and least-privilege deployment access
• Encryption in transit (HTTPS-only) and at rest (the hosting provider's standard)
• Logging, monitoring, and incident response procedures
• Regular security review of dependencies and configurations
• Documented privacy policy with user rights

For organisations that require formal certifications before adoption: Cloudflare Pages (our hosting) is SOC 2 Type 2 and ISO 27001 certified, which covers the infrastructure layer. We can provide their SOC 2 report on request. Our own certification is on the roadmap once we add a paid tier with enterprise customers.

10. How to verify the architectural claim

"Trust but verify." If you don't want to take our word for the in-browser claim, here's how to check yourself:

1. Open https://imisspdf.com/merge-pdf/ (or any tool page) in Chrome / Firefox / Safari
2. Open Developer Tools (Cmd+Option+I on Mac, F12 on Windows)
3. Switch to the Network tab and clear it
4. Drag two PDFs into the merge tool and run the merge
5. Watch the Network tab — you'll see analytics pings and a few asset requests, but no upload of your PDF. POST requests with file payloads would appear here, and they don't.
6. Right-click → "Save as" any of the analytics requests to confirm the body is metadata-only, not your file

This is the most important verification: the claim is testable from your own browser, no insider access required.

11. Contact

• Security reports: [email protected]
• General questions: [email protected]
• Privacy questions: [email protected]