Security

Dumpster Controls runs the daily operation of hauling companies: orders, dispatch, drivers, invoices and payments. That data belongs to the company that entered it, and protecting it is a condition for the software to exist, free plan included. This page explains, in plain terms, how the platform is built and operated, what is delegated to certified providers, and how to reach us if you find a problem. Everything below describes what is in production today. When something changes, this page and its date change with it.

Dumpster Controls is built and operated by Prime Systems and Controls LLC, a Florida company, part of the NexaForge group. The platform has been engineered since 2020 and in production since 2023.

1. Payments

• Stripe handles every card and bank transaction. Stripe is a PCI DSS Level 1 service provider, the highest level in the payment industry.
• Card data never touches our servers. Customers pay on Stripe-hosted pages (Stripe Checkout and Stripe Payment Links). Card numbers, CVCs and bank account details are entered on Stripe, stored by Stripe, and are never sent to or kept in the Dumpster Controls database.
• Each company is paid into its own account. Payouts run through Stripe Connect: every hauling company completes Stripe's own onboarding and identity verification, and funds settle into that company's Stripe account, not into a pooled Dumpster Controls balance.
• Webhooks are verified. Every payment event Stripe sends us is checked against Stripe's signature before anything is recorded. Unsigned or tampered events are rejected.
• Money is tracked in whole cents, with idempotent processing so a retried event cannot charge, refund or pay out twice.

2. Authentication and accounts

• Identity provider. Sign-in is handled by Supabase Auth. Passwords are never stored in clear text; sessions use short-lived signed tokens that refresh automatically and are revoked on sign-out.
• Email verification. New accounts confirm their email address before the account is fully active. Password resets go only to the verified address.
• Multi-factor authentication (MFA). Any user can enable a second factor with an authenticator app (TOTP) in Settings. Trusted devices can skip the challenge on a device the user has already verified; new devices are always challenged.
• Device lock on mobile. The driver app can require Face ID, Touch ID or the Android equivalent before it opens.
• Roles with least privilege. Owners, admins, dispatchers, drivers, customers and vendors each see only the screens and data their role needs. A driver sees the jobs assigned to that driver, not the company's finances.

3. Data isolation and access control

• One database, isolated by company at the database layer. Every business table is protected by PostgreSQL Row Level Security scoped to the company. The isolation is enforced by the database itself, not only by the application, so a bug in a screen cannot leak another company's rows.
• Anonymous access reads nothing. The public, unauthenticated role reads zero rows from business tables. Public pages (booking, invoices, the directory) go through purpose-built functions that expose only the fields those pages need.
• Server functions check the caller. Every server-side function verifies who is calling and which company they belong to before acting. A company identifier supplied by the client is never trusted on its own. Privileged service credentials exist only on the server and are never shipped to browsers or apps.
• Private files. Photos, documents and signatures live in private storage buckets and are served through short-lived signed URLs, never through public links.
• Support access is read-only and switchable. When our team helps a customer by viewing their account, that view is enforced as read-only at the database layer and can be disabled globally with a single switch.
• API keys. Keys for the public API are generated per company, shown once and stored only as a SHA-256 hash. Requests are rate-limited by IP before authentication and at 60 requests per minute per key after it. Keys can be revoked at any time.

4. Encryption

• In transit. All traffic between browsers, mobile apps, our servers and our providers uses TLS. The site enforces HTTPS with HTTP Strict Transport Security (HSTS) so browsers refuse to downgrade.
• At rest. The database and file storage are encrypted at rest by the hosting provider (AES-256 on AWS infrastructure managed by Supabase).
• Secrets. Provider credentials (Stripe, email, SMS, maps, AI) live in the managed environment of the server functions and are never included in the web or mobile bundles. The only key shipped to clients is the public one designed for that purpose, which grants no access on its own because of Row Level Security.

5. Infrastructure and providers

We build on a small number of specialised providers rather than operating our own servers. Each one publishes its own security documentation.

• Vercel serves the web application through a global edge network (SOC 2 Type II).
• Supabase runs the PostgreSQL database, authentication, private file storage and server functions on AWS (SOC 2 Type II, HIPAA-ready infrastructure).
• Stripe processes payments and payouts (PCI DSS Level 1).
• Resend delivers transactional email, ClickSend delivers SMS, Firebase Cloud Messaging delivers push notifications and Google Maps Platform provides geocoding and maps.
• AI features (the Tresha assistant) run on third-party language models reached through an API gateway. A request includes only data the signed-in user is already allowed to see, and we do not use customer data to train models.
• Datadog monitors the application for errors and performance. Monitoring data is technical (timings, error messages, page paths) and is not used for advertising.

We do not currently hold a SOC 2 or ISO 27001 certification of our own. We rely on the certifications of the providers above for the layers they operate, and we publish our own practices on this page instead of implying a certification we do not have.

6. Backups and continuity

• Database backups are automated and managed by Supabase; restores are performed by our team on request.
• Deploys are atomic and reversible. Every release is built and verified before it goes live, and any previous release can be restored in minutes. A failed build never replaces the version that is running.
• Source code is versioned on GitHub and mirrored to a second provider. Every change is reviewed and recorded in a changelog, and automated type checks and tests run on every change before release.
• Risky features ship behind switches that can be turned off without a new release.

7. Data handling

• Ownership. Operational data (customers, orders, drivers, trucks, invoices) belongs to the company that entered it. Dumpster Controls processes it to run the service, as described in the Privacy Policy.
• Driver location. Position history from the driver app is kept for 30 days; aggregated figures (miles, times) may be kept longer. Companies that enable shift tracking limit recording to the shift.
• Server logs are kept by the provider for a limited window and used only for troubleshooting and security investigation.
• Deletion. Accounts and their data can be deleted on request through the account deletion page or by email. Records that must be kept for tax or payment-dispute reasons are retained only for the legally required period.
• No sale of data. We do not sell customer or operational data, and we do not use it for third-party advertising.

8. Responsible disclosure

If you believe you have found a security vulnerability in Dumpster Controls, please tell us before telling anyone else. Email support@dumpstercontrols.io with "Security" in the subject line. The same contact is published at /.well-known/security.txt.

What we commit to

• Acknowledge your report within one business day.
• Keep you informed while we investigate and fix the issue.
• Not pursue legal action against research done in good faith under the rules below.
• Credit you publicly if you want, once the issue is fixed.

Rules for good-faith research

• Only test accounts and data you own or are explicitly authorised to use. Never access, modify or delete another company's data.
• No denial-of-service, spam, social engineering or physical attacks.
• Stop and report as soon as you confirm a vulnerability. Do not use it to pivot further.
• Give us a reasonable time to fix the issue before any public disclosure.

In scope

dumpstercontrols.io and its subdomains, the web application, the public API and the Dumpster Controls mobile apps.

Out of scope

Vulnerabilities in third-party providers (Stripe, Supabase, Vercel and the others listed above), which should be reported to those companies directly, and issues that require a compromised device or physical access.

9. Questions

Security questionnaires, data processing agreements and enterprise requirements: write to support@dumpstercontrols.io. Company facts and the full entity chain are on the About page; the plain-text version of this page for AI assistants is at /security.md.

Frequently asked questions