How we protect podfy.app and podfy.net

1. Overview

Security governance & approach

Security at PODFY is treated as a product feature, not an afterthought. Day-to-day decisions are made with the mindset of a combined CISO and Head of Engineering: keep the surface small, use modern platform controls, and remove fragile moving parts where possible.

We focus on:

• Minimal stack: static front-end, edge functions, managed storage.
• Tenant isolation: every customer’s data is kept logically separate.
• Operational clarity: straightforward flows for uploads, delivery portals and retention.

This page is a high-level description. For a more formal statement of researcher rules and safe harbor, see SECURITY.md and /.well-known/security.txt.

2. Infrastructure & transport security

Cloud platform, network & TLS

Hosting platform

• PODFY runs on Cloudflare’s edge platform, including Cloudflare Pages and Workers.
• POD documents and files are stored in a managed object store (e.g. Cloudflare R2) with encryption at rest.
• Metadata and configuration live in a managed SQL-like store (e.g. Cloudflare D1) with access limited to the application layer.
• We maintain a clear distinction between production and non-production environments.

Transport security

• All PODFY domains enforce HTTPS; HTTP is redirected to HTTPS.
• .app is an HSTS-preloaded TLD; podfy.app is HTTPS-only by design.
• We support TLS 1.2+ and enable HTTP/3/QUIC at the edge where available.

Edge & perimeter

• We rely on Cloudflare’s DDoS protection, WAF, and rate limiting for first-line defence.
• Additional rules can be applied for sensitive routes (authentication, uploads, delivery portals).
• No direct SSH/RDP into production; changes are deployed via CI/CD pipelines.

Secrets & configuration

• Secrets (API keys, signing keys) are stored in the platform’s encrypted secrets store, never in source control.
• Configuration is environment-specific and shipped via deployment pipelines.

Logging & observability

• We log key application and edge events (errors, uploads, portal access) with minimal necessary personal data.
• Access to logs is restricted to staff who need them for operations, security or support.

3. Application

podfy.app – product & data security

podfy.app is where customers configure their POD flows, upload documents and grant access to drivers and partners. It is treated as the main security boundary.

Tenant isolation & access control

• All customer data is logically isolated at the data layer (tenant IDs, scoped queries, and access checks).
• Role-based access control defines which users can configure settings, view documents, or export data.
• Access to specific PODs can be further restricted with signed URLs and unguessable tokens.

Authentication & sessions

• Authentication is always over HTTPS and uses secure cookies or tokens, with Secure and HttpOnly where applicable.
• Sessions have reasonable expiry and may be invalidated when account-level changes or security events occur.

POD uploads, processing & retention

• Uploads accept a controlled set of file types used for PODs (PDF and relevant image formats).
• PODFY progressively standardises inputs into a branded PDF where possible, keeping originals only when needed.
• Objects are stored in encrypted object storage; metadata sits in a database tied to your tenant.
• Retention windows are configurable per customer; after expiry, files are scheduled for deletion from primary storage.

Delivery portals & email-based access

• Drivers and partners can access PODs via emailed links containing long, unguessable tokens.
• Tokens are validated server-side and may be time-limited and scoped to specific PODs or shipments.
• We avoid embedding sensitive data in query strings; the token is a reference, not the data itself.
• Portal views can be logged with timestamp, token reference and basic user-agent for auditability.

4. Website

podfy.net – website, forms & email flows

podfy.net is our public site for marketing, documentation and legal content. It intentionally has a smaller attack surface than the operational app.

Architecture

• Deployed as a static site via Cloudflare Pages, with dynamic behaviour handled by Workers functions.
• No direct database access from the browser; form submissions go through backend handlers.

Forms & spam protection

• Contact and configuration forms use Cloudflare Turnstile or similar to reduce automated abuse.
• Input is validated server-side before being written to storage or forwarded by email.
• We collect only the information needed to respond to your request. See the Privacy Policy for details.

Emails, templates & portal links

• Emails (auto-replies, portal invitations, driver notifications) are rendered from controlled templates.
• Static branding (logos, layout) is separated from dynamic content (links, names, references) to reduce template errors.
• Links in emails always use HTTPS and the official PODFY domains.

Cookies & tracking

• PODFY follows a low-cookie approach; we avoid marketing and third-party tracking cookies.
• Any future non-essential cookies would be documented in the Cookie Policy and would require consent where required by law.

5. Data protection

Data protection, roles & sub-processors

From a data protection perspective, PODFY typically acts as:

• Data processor for POD documents and related operational data stored in podfy.app.
• Data controller for website visitor data, account data and commercial contact details on podfy.net.

Principles

• Minimisation: collect only what is needed for POD workflows, support, and operations.
• Purpose limitation: no reuse of Customer Data for unrelated advertising or profiling.
• Access limitation: internal access granted on a need-to-know basis and logged where appropriate.

DPA & international transfers

• For GDPR-regulated customers, we provide a Data Processing Addendum (DPA) covering processor obligations and, where required, Standard Contractual Clauses (SCCs).
• Where sub-processors are located outside the EU/EEA, we rely on SCCs or equivalent safeguards in line with applicable law.

Sub-processors

• Cloud infrastructure and edge provider(s) (for hosting, storage, DNS and security).
• Email delivery provider(s) for transactional emails and portal links.
• Support tooling for handling tickets and operational communication.

Additional privacy details, including lawful bases and data subject rights, are covered in the Privacy Policy and Terms of Service.

6. Incidents

Incident response & monitoring

We treat security incidents as first-class operational events. The people shipping features are expected to understand how to contain, fix, and learn from incidents.

Incident response lifecycle

• Detection: via monitoring, internal testing, customer reports or researcher reports.
• Triage: classify severity (Critical / High / Medium / Low) based on data sensitivity, exploitability and blast radius.
• Containment: revoke tokens, rotate keys, roll back or hot-patch where required.
• Eradication & recovery: fix root cause, validate integrity, restore from backups if needed.
• Post-incident review: document the incident and implement follow-up actions at code, configuration or process level.

Remediation targets (guideline)

• Critical issues: aim to mitigate or fix within 7 days.
• High issues: aim to fix within 30 days.
• Medium issues: aim to fix within 90 days.
• Low issues: aim to fix within 180 days.

Where required by law, affected customers and authorities will be notified without undue delay in case of a personal data breach.

7. Researchers

Vulnerability reporting & responsible disclosure

If you believe you have found a security issue in podfy.app or podfy.net, we want to hear from you. Responsible disclosure helps keep logistics data safe for everyone using PODFY.

How to report

• Email: [email protected]
• Include: a clear description, affected URLs/endpoints, reproduction steps, and impact assessment.
• If your report contains sensitive data, mark it clearly; we can arrange an encrypted channel if needed.

What to expect

• Acknowledgement within 3 business days.
• Initial triage within 7 business days.
• Remediation based on the severity targets described above.
• Coordinated disclosure: we prefer that details are shared publicly only after a fix or effective mitigation is in place.

Rules of engagement (good-faith testing)

• Do not access, modify or exfiltrate data that does not belong to you.
• Avoid impacting availability (no load tests, DoS or large-scale automated scanning against production).
• Do not use social engineering, phishing, or physical intrusion.
• Use test accounts and sample data wherever possible; stop immediately if you encounter real third-party personal data and report the issue.