Security at PDFWhirl

1. Our security philosophy

PDFWhirl is built around three principles that shape every security decision. Ephemerality: files exist in our systems for as short a time as possible, ideally only long enough to complete the requested action and deliver the output. Least privilege: every component — a request handler, a background worker, a database user, an engineer's laptop — has the minimum set of permissions necessary to perform its role, and no more. Observability: we assume that controls can fail silently, so we log, alert, and review behaviour continuously to detect problems quickly. These three principles are the lens through which we evaluate every new feature, every third-party vendor, and every operational change. When they conflict with convenience — for example, with the idea of caching a frequently-requested file — ephemerality wins, even if it costs us a little more compute.

We also follow an explicit "defence in depth" posture. No single control is relied upon to keep data safe: TLS in transit is backed by encryption at rest, which is backed by short retention, which is backed by network isolation, which is backed by logging, and so on. If any layer is bypassed or misconfigured, other layers should still protect the user.

2. Encryption in transit

Every connection between a browser or API client and PDFWhirl is protected with TLS 1.2 at minimum, with TLS 1.3 negotiated wherever the client supports it. We terminate TLS at the edge of our content delivery network using certificates issued by well-known public certificate authorities. The following edge security behaviours are enforced on every request:

• HSTS (HTTP Strict Transport Security) is set with a long max-age and preload, so browsers refuse to make plain-HTTP connections even if tricked by a downgrade attempt,
• only modern cipher suites are accepted; deprecated protocols including SSLv3, TLS 1.0, TLS 1.1, and export-grade ciphers are disabled,
• OCSP stapling is enabled to minimise the privacy and latency cost of certificate revocation checks,
• Certificate Transparency is enabled, so all issued certificates appear in public logs and can be audited by third parties, and
• internal service-to-service traffic in the backend uses mTLS or equivalent authentication so workers cannot be impersonated by compromised neighbours.

3. Encryption at rest

Temporary object storage used to hold uploaded files and processed outputs relies on AES-256 server-side encryption provided by our object storage vendor. Database volumes that hold operational state are attached with volume-level encryption enabled, and backups are encrypted before leaving the production environment. Where we hold secrets — API tokens, TLS certificates, webhook signing keys — those secrets are kept inside a dedicated secrets manager with its own access controls and audit logging, not stored in plain-text config files or in repository histories.

4. Deterministic file retention

The two-hour retention policy advertised on the site is backed by multiple independent mechanisms so a single failure cannot cause files to persist indefinitely:

• Each uploaded object is written with a lifecycle rule that deletes it after two hours, enforced by the storage provider irrespective of application behaviour,
• A background job runs every 30 minutes to identify objects that should have been cleaned up already and delete them,
• A daily sweep checks the age distribution of objects in the storage bucket and alerts the on-call engineer if any object older than the retention window is detected,
• Request metadata that references a file is purged as soon as processing completes, so even an internal lookup cannot resurrect it.

The retention window is a ceiling rather than a target. In the typical case, a file is deleted within minutes of the user downloading the output. The two-hour maximum exists to account for users who pause a multi-step workflow and come back to download the result later.

5. Processing isolation

Each PDF operation runs in an isolated processing environment. Workers are stateless containers with tightly scoped IAM roles, limited outbound network reachability, and no persistent disk beyond the scratch space used by the current job. We do not share a worker's scratch space across requests; once a job completes, its scratch area is cleaned and the worker is either reset or replaced entirely. We treat untrusted PDF input as potentially malicious and therefore run the parsing code with the principle that a crash or exception inside the job must not compromise the host.

6. Network and edge security

The edge of our network is protected by a commercial content delivery network that provides DDoS mitigation, bot management, rate limiting, and a web application firewall. The following controls are active for every inbound request:

• automatic blackholing of traffic spikes identified as volumetric DDoS attacks,
• rate limits on expensive endpoints so a single source cannot monopolise the processing pipeline,
• web application firewall rules that block common injection patterns, malformed requests, and known-bad user agents,
• bot management that distinguishes between legitimate crawlers, benign automation, and hostile scraping,
• security headers set on every response, including Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin, Cross-Origin-Opener-Policy, and Permissions-Policy,
• strict CORS rules on API endpoints so only first-party origins can make authenticated calls, and
• IP reputation filtering that throttles sources known to host abuse.

7. Authentication and access control

End users do not need an account to use the free tools, which dramatically reduces the attack surface — there are no stored password hashes to leak and no credential-stuffing risk. For internal access to production systems, we apply the following controls:

• every administrator authenticates with single sign-on backed by phishing-resistant multi-factor authentication (hardware security keys or equivalent),
• privileged actions require an additional re-authentication within a short time window,
• long-lived API tokens are avoided in favour of short-lived, audited credentials,
• access grants are reviewed on a regular cadence and revoked as soon as an engineer no longer needs them,
• break-glass credentials are stored in a dedicated secrets vault and monitored separately, and
• all administrative access is tied to a named human identity, never to shared role accounts.

8. Logging, monitoring, and alerting

We collect structured logs from the edge, the application, and the data tier. Logs are shipped to a central logging platform where they are retained for the period described in the Privacy Policy. Anomaly-detection rules are layered on top of that data to spot unusual patterns such as spikes in 500-class errors, sudden changes in upload volume, unexpected access to sensitive endpoints, and failed authentication attempts clustered around a specific account or IP range. When such a signal fires, an engineer is paged immediately.

9. Vulnerability management

Our vulnerability management programme covers the full life cycle of a finding: discovery, triage, prioritisation, remediation, and verification. Inputs include automated dependency scanning, container image scanning, dynamic web-application scanning, penetration tests, reports from our bug-bounty inbox, and the public advisories we follow for every component in our stack. Findings are prioritised using a CVSS-based rubric adjusted for our specific deployment context. Critical findings are fixed within 24 hours, high findings within 7 days, medium findings within 30 days, and low findings within 90 days, unless a compensating control is already in place.

10. Supply-chain security

We treat the software we ship as the tip of an iceberg: most of the bytes that end up running in production come from open-source libraries, base container images, and managed services we did not write. To manage the risk of that supply chain, we:

• pin dependency versions and use lockfiles, so an install always produces the same tree,
• run automated scanners that check each lockfile against vulnerability databases,
• review every dependency update for suspicious changes before merging,
• build container images from trusted, minimal base images and rebuild them on a regular cadence,
• produce a software bill of materials for critical artefacts so we know exactly what is shipped,
• sign release artefacts and verify signatures at deploy time, and
• maintain a short list of critical vendors whose incident notifications we actively monitor.

11. Application security controls

Within the application we enforce a set of controls designed to block the classes of vulnerability that show up most often in web software:

• Input validation at the boundary of every tool, so malformed requests fail fast with a predictable error,
• Output encoding in all HTML templates to prevent cross-site scripting,
• Parameterised queries in the data layer so SQL injection is structurally impossible,
• CSRF protection on state-changing endpoints via double-submit tokens,
• Content Security Policy in report-only mode during development and enforced in production to limit the impact of any residual XSS,
• Size limits on uploads and processing jobs to defend against resource exhaustion,
• File-type verification based on actual byte content rather than the user-supplied extension, so a renamed executable cannot bypass a PDF-only tool, and
• Memory-safe code paths where possible, with defensive wrappers around C-backed libraries that handle untrusted document input.

12. Data protection by design

The design decisions described in the Privacy Policy are themselves security controls. Collecting less personal data reduces the blast radius of any incident. Deleting files quickly reduces the window in which a stolen credential could be used to exfiltrate them. Not training any model on user content eliminates a category of data-leakage risk entirely. Where we can avoid collecting a piece of data, that is our default choice.

13. Incident response

We maintain an incident-response runbook that assigns clear roles — incident commander, communications lead, subject-matter experts — and walks through the phases of detection, containment, eradication, recovery, and post-mortem. For security-relevant incidents the runbook adds a formal decision point about regulatory and user notification. Post-mortems are blameless, written up within a week of the incident, and track concrete action items to closure.

Where an incident triggers notification obligations under the GDPR, the LGPD, the CCPA/CPRA, or any other applicable regulation, we aim to meet the strictest relevant deadline — typically 72 hours from confirmed discovery. Affected users are notified through the communication channel that is best suited to the situation, for example a homepage banner, an email to known affected users, or a public post-incident report.

14. Business continuity

Our infrastructure is designed to survive routine failures without user impact. Stateless components are run in redundant pairs across multiple availability zones. Data that needs to persist beyond a request is written to managed services with automatic failover. We periodically test backup restoration to make sure that an actual recovery can be performed within the target recovery-time objective, not just that the backup job completed successfully.

15. People and training

Everyone who works on PDFWhirl — whether on the engineering, operations, support, or product side — goes through a baseline security training on joining and refresher training at least once a year. The training covers phishing recognition, password and device hygiene, safe handling of data we process for users, and the specific security-sensitive patterns of our codebase. We also run periodic phishing simulations to test preparedness and identify areas for further training.

16. Subprocessors and vendor security

Before bringing on a new vendor that will process data on our behalf, we review the vendor's security posture. Depending on risk, the review may include questionnaires, independent audit reports (SOC 2, ISO 27001), data-processing addenda, and contractual commitments on data-protection practices. We prefer vendors that can demonstrate a strong baseline through independent audits and transparent incident history.

17. Compliance and frameworks

PDFWhirl's operations are informed by widely-recognised security frameworks, including ISO/IEC 27001, the NIST Cybersecurity Framework, the OWASP Application Security Verification Standard, and CIS benchmarks. Where a specific certification is pursued, we will publish its status here. Independent of any certification programme, we hold ourselves to the implementation guidance of those frameworks as a baseline for design and operational choices.

18. Responsible disclosure

We welcome security research on PDFWhirl. If you believe you have discovered a vulnerability, please send a report to security@pdfwhirl.com with enough detail to reproduce the issue. We commit to:

• acknowledge receipt of your report within 2 business days,
• provide a status update within 5 business days,
• keep you informed as triage and remediation progress,
• credit you publicly once the issue is fixed, if you wish to be credited, and
• refrain from legal action against researchers who act in good faith, stay within the scope described below, and do not cause harm to users or the service.

In scope: pdfwhirl.com and its documented subdomains, the public PDF tools, and the content pages. Out of scope: denial-of-service testing, automated scanning that affects service availability, social engineering of staff or users, and attacks that require compromise of a user's personal device. Please do not access, modify, or delete data that belongs to someone other than yourself, and please do not publicly disclose a vulnerability before we have had a reasonable chance to fix it.

19. Contact

Security reports and vulnerability disclosures: security@pdfwhirl.com. Privacy questions: privacy@pdfwhirl.com. General support: support@pdfwhirl.com. For broader product questions, our contact page lists the right mailbox for each type of enquiry.