Security at LoadOut

• Identity gateway. Cloudflare Access verifies an authorized email identity before the protected application opens.
• Optional second factor. Users may add authenticator-based two-factor authentication to their LoadOut account.
• Session controls. Protected requests are tied to authenticated sessions and rejected when identity requirements are not met.
• Administrative control. Workspace administrators control invitations, membership, and operational roles.

LoadOut checks authorization on the server for protected data and actions. Role checks determine whether a User may perform sensitive operations. Records are scoped to the authenticated workspace rather than relying on interface visibility alone.

Sensitive changes generate operational history so teams can identify who performed an action and when. The application treats browser inputs, record identifiers, redirect parameters, and entitlement claims as untrusted and validates them at the service boundary.

• Network traffic is protected with HTTPS while moving between a supported browser, Cloudflare, LoadOut, and connected service providers.
• Structured application data is stored in Cloudflare D1 and accessed through workspace-scoped application controls.
• Uploaded photographs and evidence are stored in private Cloudflare R2 object storage and delivered through authenticated application requests rather than public object links.
• Service credentials and signing secrets are kept outside client-side application code and are available only to the server components that need them.

Additional information about personal data, providers, and retention appears in the Privacy Policy.

Stripe hosts payment-card entry, checkout, invoices, and the customer billing portal. LoadOut does not use a browser redirect, plan name in a request, or client-side state as proof of payment.

Paid entitlements change only after LoadOut validates a cryptographically signed Stripe event and matches its subscription and price data to an allowed plan. Billing events are processed idempotently so a retry cannot apply the same event twice. Webhook traffic is isolated from the human sign-in surface and restricted to the expected request shape and trusted provider network.

LoadOut applies validation and explicit state transitions to operational actions such as booking, load verification, returns, cleaning, repair, and quality control. Critical checks are performed by the server so they cannot be bypassed merely by changing browser markup or request fields.

Request paths, methods, origins, and payload sizes are constrained where appropriate. Errors returned to Users are designed to be useful without exposing credentials, private records, or internal exception details.

Security-relevant authentication, billing, and operational activity produces logs or audit records used to investigate unexpected behavior. When we identify a suspected incident, our response is to validate scope, contain access, preserve relevant evidence, correct the underlying issue, and notify affected customers or authorities when required by law.

No internet service can eliminate every risk. We review material reports and improve controls as the service and threat environment evolve.

• Enable authenticator-based two-factor authentication.
• Use a unique, protected email account and review sign-in prompts before approving them.
• Give each User the least-privileged role needed for their work.
• Remove departed personnel and obsolete invitations promptly.
• Keep browsers and devices updated, encrypted, and protected by a screen lock.
• Do not upload payment-card numbers, authentication secrets, or unrelated sensitive personal information as operational notes or evidence.
• Report unexpected account, workspace, or billing activity immediately.

We welcome good-faith reports that help protect LoadOut customers. Email support@loadoutoperations.com with a clear description, the affected surface, reproduction steps, potential impact, and any non-sensitive evidence needed to understand the issue. Please allow reasonable time for investigation and remediation before public disclosure.

When researching or reporting an issue:

• use only accounts, workspaces, and data that you own or have explicit permission to test;
• stop if you encounter another person’s data and report the exposure without retaining or sharing it;
• do not perform denial-of-service testing, social engineering, phishing, physical attacks, spam, or destructive actions;
• do not modify or delete data, degrade service, establish persistence, or access more information than needed to demonstrate the issue; and
• do not include passwords, session tokens, authentication codes, payment details, or unnecessary personal information in the report.

This process does not create a bug bounty, promise payment, authorize testing of third-party systems, or waive legal rights. Reports about Cloudflare or Stripe systems should also follow those providers’ disclosure processes.

Customers evaluating LoadOut may send security and data-handling questions to support@loadoutoperations.com. Please do not request or send production credentials, signing secrets, private architecture details, or another customer’s information.