Security

The threat model

Ask what an attacker would want from a PDF site and the answer is obvious: other people's documents. Contracts, invoices, medical letters, identity scans. On a normal PDF service those sit on a server, at least briefly, and that server is the prize.

We do not have one. Your file is opened, edited and saved inside your own browser, so there is no pile of documents anywhere to steal. Breaking into our hosting would get someone a copy of the same public website you are reading now.

The strongest control on this site is an absence. No upload endpoint, no queue, no temporary folder, no backups of your files, because your files never arrive.

What is not there to attack

• No user accounts, passwords or sessions. Nothing to phish, nothing to stuff credentials into.
• No database. No stored personal data to dump.
• No file storage. Nothing is written to a disk we control, not even briefly.
• No application server, no API routes and no server-side code. The whole site is static files.
• No file handling on our infrastructure, so the classic command-injection and parser bugs that hit server-side PDF pipelines have nowhere to happen.

That last one is not theoretical. It is the bug that made us build the site this way.

What is left

An honest security page names the real surface rather than declaring victory. Ours:

• The static hosting itself. If it were compromised, an attacker could serve altered JavaScript to visitors. This is the one that would actually matter, and it is why we self-host every library instead of pulling code from third-party CDNs at page load.
• The client-side libraries. A flaw in a PDF parser can in principle be triggered by a malicious document. Here that runs in your browser's sandbox against a file you already had, rather than on a shared server holding other people's documents.
• The analytics tag, which is third-party code and only loads if you agree to it.
• The contact form, which is handled by an external form provider. It sees what you type into it and nothing else.
• The domain and DNS, the way they matter for any website.

We keep the third-party list this short deliberately. Every extra script is a party that can change what runs on your machine.

Dependencies

The PDF work relies on pdf.js from Mozilla, pdf-lib and JSZip. All three are open source, widely used, and served from our own domain rather than fetched from elsewhere while you browse. We update them when upstream ships a security fix.

The site is built with Next.js and exported to plain static files, so none of the framework's server features are in play.

Reporting a problem

If you have found something, please tell us before telling the internet. Email hello@pdfsansar.com with:

• What you found and which page or tool it affects.
• The steps to reproduce it, and what a real attacker could do with it.
• Your browser and operating system, if it only happens on some setups.

We aim to reply within five working days. We are a small team, so we cannot pay bounties, but we will fix what is real, tell you when it is done, and credit you if you would like that.

Please do not run automated scanners against the site, and do not test anything that would affect other visitors.

Scope

In scope: pdfsansar.com and the tools on it.

Out of scope: reports from automated tools with no working proof, missing headers with no demonstrated impact, issues in third-party services we only use rather than run, and anything that needs physical access to someone's unlocked device.

For anything that is not a security issue, the contact page is the better route.