Security & Trust Center

Data Handling

Filtrate is designed to minimise data exposure at every step. Image bytes arrive, get processed in-memory, and the processed result goes to storage. The original never does.

Image Lifecycle

1. Image received in-memory only

Uploaded bytes land in Node.js process memory (multer memoryStorage). Nothing is written to disk. Render's ephemeral filesystem is never touched for image data.

2. EXIF/metadata stripped

Sharp processes the input buffer with .webp({ quality }) — no .withMetadata() call, so all EXIF, IPTC, XMP, and GPS tags are stripped before any downstream step.

3. MD5 hash computed hash only — no image bytes

An MD5 of the original input is used as a cache key for AI moderation verdicts. The hash is stored in verdict_cache. No image bytes are stored alongside it.

4. Processed WebP uploaded to R2 EXIF-clean

Only the processed, metadata-free WebP output is stored via Cloudflare R2 (Polsia proxy). The original input bytes are never written anywhere. Original bytes leave memory when the request ends.

5. Compliance verdict returned

AI moderation runs on the processed WebP (after EXIF strip). Result is returned to the caller and optionally cached by MD5. No PII leaves this step.

Retention Summary

Original image bytes

Never persisted

In-memory only. Discarded when request completes.

Processed WebP output

Stored in R2

EXIF-clean WebP, CDN-delivered. Accessible via the URL returned in the API response.

Usage logs

18 months

API key ID, timestamp, endpoint. Used for billing. No image content.

Verdict cache

Indefinite

MD5 hash → moderation verdict. No PII, no image bytes.

Processing records

Indefinite

Timing metrics, sizes, verdict label. No image content.

Processing region

AWS us-east-1

Render + Neon hosted in US East. EU residency on roadmap.

Encryption

All data is encrypted in transit and any persisted data is encrypted at rest.

🔒

TLS 1.3 in transit

All traffic to filtrate.polsia.app is served over TLS 1.2+ (TLS 1.3 preferred). HTTP is not served. HSTS is configured at the CDN/load balancer layer (Render + Cloudflare). Cipher suite selection follows Render's managed TLS defaults, which enforce forward secrecy.

🛡️

AES-256 at rest for persisted metadata

Neon PostgreSQL (database) and Cloudflare R2 (processed image storage) both encrypt data at rest using AES-256. Encryption keys are managed by the respective sub-processor with annual rotation cadence. Render (compute) uses volume-level encryption on ephemeral disks.

🔑

API keys bcrypt-hashed at rest

API keys are bcrypt-hashed before storage (cost factor 10+). The plaintext key is shown only once at generation and is never logged or stored in recoverable form. Keys are rotatable on demand from the dashboard. Compromised keys can be revoked instantly without changing application logic.

Sub-Processors

We use a small, stable set of third-party processors. All are SOC 2 certified or equivalent. If a new processor is added, we will update this page and notify enterprise customers with at least 30 days notice.

Processor	Purpose	Data Shared	Region	DPA / Security Docs
Render	Application hosting — runs the Express API server	All inbound API traffic; no data stored by Render beyond logs	us-east-1 (AWS)	render.com/dpa
Neon	PostgreSQL database — stores usage logs, API keys (hashed), invoices, and verdict cache	API key hashes, usage metadata, billing records. No image bytes.	us-east-1 (AWS)	neon.tech/privacy
Cloudflare R2	Object storage — stores processed (EXIF-stripped) WebP output images	Processed WebP bytes only. Original input never reaches R2.	Global (Cloudflare network)	cloudflare.com/trust-hub
OpenAI	AI content moderation — GPT-4o-mini vision evaluates the processed WebP for compliance flags	Processed WebP bytes (post-EXIF-strip). No original input, no PII from your users. Images are not used to train OpenAI models per API usage policy.	US (OpenAI API)	openai.com/policies
Stripe	Payment processing — Stripe-hosted Checkout for invoice payment; Billing Portal for self-serve management	Customer billing contact (email), payment method. No image data.	US (Stripe servers)	stripe.com/privacy
Postmark	Transactional email — invoices, API key notifications, billing receipts	Recipient email address, email body content (invoice data). No image data.	US (Postmark servers)	postmarkapp.com/privacy-policy

Compliance Posture

Filtrate operates as a data processor under GDPR Art. 28 — we process images on behalf of marketplace operators (the controllers). Our standard DPA is available for download below.

GDPR

Compliant

Filtrate is a processor under GDPR Art. 28. We process image data per your instructions and do not use it for any other purpose. Standard DPA available — download below or email security@filtrate.polsia.app.

CCPA

Compliant

We do not sell or share personal information as defined by CCPA. API usage metadata is used solely for billing. Processed image content is not linked to end-user identity.

SOC 2

Roadmap Q4 2026

SOC 2 Type I is targeted for Q4 2026 — currently in scoping. We have not yet initiated a formal audit engagement. We will update this page when the audit is underway and share the report with customers under NDA once complete.

ISO 27001

Roadmap

ISO 27001 certification is on the security roadmap. Currently implementing ISMS controls as part of SOC 2 preparation.

PCI DSS

Not in scope

Filtrate does not process, store, or transmit payment card data. All payments are handled by Stripe's PCI-compliant hosted Checkout. Filtrate is not a payment processor.

EU Residency

Roadmap

Processing currently occurs in AWS us-east-1. EU-resident processing is on the roadmap. EU customers may request Standard Contractual Clauses (SCCs) and dedicated DPA provisions in the interim.

Data Processing Agreement (DPA)

Enterprise and GDPR-regulated customers often require a signed DPA before going live. We provide a standard template you can use as-is or propose amendments to.

The DPA template is an HTML file — open in your browser and use Print → Save as PDF to produce a PDF. If you require amendments or a Word document version, email security@filtrate.polsia.app.

Security Practices

How we protect the API, your keys, and your data in transit and at rest.

🔒

TLS 1.3 enforced, HSTS

All traffic to filtrate.polsia.app is served over TLS 1.2 or higher (TLS 1.3 preferred). HTTP is not served. HSTS is configured at the CDN/load balancer layer. Cipher suite selection follows Render's managed TLS defaults, enforcing forward secrecy on all connections.

🔑

API keys: bcrypt-hashed at rest, rotatable on demand

API keys are bcrypt-hashed before storage. The plaintext key is shown only once at generation and is never logged or stored in recoverable form. Keys are rotatable at any time from the dashboard. Compromised keys can be revoked and replaced without changing application logic.

🛡️

Admin endpoints gated by X-Admin-Token

All internal admin routes (/admin/*) require a shared secret passed as the X-Admin-Token header. These endpoints are not accessible from the public API surface and are not documented in the public reference.

📦

Original image bytes never persisted

Uploaded images are held in Node.js process memory only (multer memoryStorage — no temp files). Render's ephemeral disk is never written to for image data. Original bytes are discarded when the request ends. Only the processed, EXIF-stripped WebP is stored.

🔍

Dependency scanning via GitHub Dependabot

Dependabot monitors npm dependencies for known CVEs and opens pull requests automatically. Critical and high-severity advisories are triaged within 48 hours of notification.

🚨

Incident response: 24h initial notification SLA

If a confirmed breach affecting customer data occurs, affected customers will receive initial notification within 24 hours of confirmation, and a regulatory-compliant notification (where required) within 72 hours. Notifications include the nature of the incident, data affected, and remediation steps taken.

🔐

Session security

Web sessions are stored in PostgreSQL (connect-pg-simple), not in-process memory. Session cookies are HttpOnly and Secure in production. Session secrets rotate on deployment. Sessions expire after 30 days of inactivity.

Vulnerability Disclosure

We follow a coordinated disclosure model with a 90-day window. If you find a security issue, we want to hear from you.

Responsible Disclosure Policy

Report security vulnerabilities to security@filtrate.polsia.app. Please include: a description of the issue, steps to reproduce, your assessment of severity (CVSS score if possible), and whether you'd like to be credited publicly.

Our commitments:

• We will acknowledge your report within 2 business days.
• We will provide a status update within 7 days confirming whether the issue is valid and our intended timeline.
• We operate a 90-day coordinated disclosure window — we ask that you do not publicly disclose the issue during this period while we work on a fix.
• We will credit researchers by name in our release notes (or maintain anonymity at your request).
• There is no bug bounty programme at this time; we appreciate the community's help and will acknowledge all valid reports.

We ask that you do not exploit or exfiltrate data, perform denial-of-service attacks, or access accounts that are not your own while researching potential issues.

Status & Uptime

Real-time API availability and historical uptime.

Operational

All systems operational. Public status page coming Q3 2026 — it is on the roadmap and will be linked here when live. For incident reports in the meantime, email security@filtrate.polsia.app or check the changelog for service announcements.

Security questionnaire, DPA, or pen-test report?

Email us directly at security@filtrate.polsia.app, or use this form — we respond within 1 business day.