Security & data handling

Last updated: 2026-07-14

This page is written for developers evaluating SubmissionBuddy. It describes what actually happens to a submission, not marketing language — every claim below reflects how the pipeline is built.

Durable-write-before-acknowledge

When a submission hits our ingestion endpoint, we write the raw payload to object storage (Amazon S3) before we publish a queue message and before we return a response. If anything downstream fails after that point, the raw submission already exists in durable storage and can be replayed.

Reference-based queues

Queue messages never carry the submission payload itself — only a reference to it (an S3 key and a form ID). Each processing stage fetches the payload it needs from storage using that reference. This keeps queue messages small and means a stage can be retried without re-transmitting data.

Automatic retries

Each pipeline stage runs as an independent queue consumer. If a stage fails (a transient database error, a downstream timeout), the message becomes visible again after a timeout and is redelivered automatically — you don't need to build your own retry logic on top of us.

Idempotent processing

Processing a submission twice (for example, after a retry) doesn't create a duplicate record. We insert submissions keyed on the S3 object reference with a conflict-safe insert, so a redelivered message is a no-op rather than a duplicate.

Encryption

• All traffic to and from SubmissionBuddy is encrypted in transit via TLS/HTTPS.
• Submission data at rest in S3 is encrypted with AES-256 server-side encryption (SSE-S3).
• Our S3 bucket has public access fully blocked at the bucket level — submissions are never publicly reachable by URL.

Data retention

• Raw submission payloads in S3 are automatically deleted 30 days after ingestion via a storage lifecycle rule.
• The processed submission record shown in your dashboard is retained indefinitely — it doesn't expire on its own. It's deleted only when you delete it or close your account.

Rate limiting

Every submission is checked against two independent rate limits before it's accepted:

• Per form, per IP: 10 requests per minute by default (form owners can adjust this).
• Global, per IP: 60 requests per minute across all forms.

Rate limits are enforced against a durable store (not in-memory), so they hold up across concurrent requests and Lambda invocations. Requests over the limit get an explicit 429 response.

Spam and abuse protection

• Honeypot fields: a hidden field name you control. If it's filled in, the submission is dropped silently — no storage, no notification — while the sender still sees a normal-looking success response, so bots don't learn they were caught.
• Risk scoring: submissions are scored based on signals like honeypot triggers, CAPTCHA failures, origin mismatches, and rate-limit pressure. Risk scores are informational and visible in your dashboard — they never block a submission on their own.
• CAPTCHA (paid plans): our CAPTCHA is a self-hosted proof-of-work challenge. The browser solves a small computational puzzle; we verify it entirely on our own servers using an HMAC-signed, expiring, one-time-use challenge. There are no calls to a third-party CAPTCHA provider, no cookies, and no cross-site tracking involved.

Data location

Our infrastructure runs on AWS in the United States (us-west-2). Our database is hosted in the United States.

Access control

The database role our application uses to read and write submission data is scoped to only the operations the application needs — it is not a superuser or admin role.

Questions

If you have a question we haven't answered here, email support@submissionbuddy.io.