Security Control Inventory

All connections between the browser and The Forge use HTTPS with TLS encryption enforced by the hosting provider.

A Content Security Policy restricts which scripts, styles, images, fonts, and network connections the browser is allowed to load, and blocks page framing, plugin content, and base-URL hijacking to limit the impact of content-injection attacks.

Additional security headers are set on all responses: X-Frame-Options DENY, X-Content-Type-Options nosniff, Referrer-Policy strict-origin-when-cross-origin, Permissions-Policy, and HSTS.

Sessions use HttpOnly, Secure, SameSite=Lax cookies carrying only an opaque signed session identifier; sessions are validated server-side on every request and can be revoked server-side. Sessions expire automatically after a fixed 12-hour lifetime.

The Forge is accessible through supported mobile browsers with the same authentication and session protections as desktop access.

Public-facing forms are protected by a challenge service (Cloudflare Turnstile) to resist automated abuse without CAPTCHAs that punish real users.

Each user gets an individual account provisioned by invitation; activation requires a single-use invitation token delivered to the user's email address, so actions can be attributed to the correct person.

User passwords must meet a minimum length requirement. Passwords are stored using PBKDF2-SHA256 with 100,000 iterations, a per-user salt, and constant-time comparison — never in plaintext.

Repeated failures trigger escalating temporary lockout applied before password processing, plus edge-level rate limiting, to resist brute-force attacks.

TOTP authenticator apps with one-time recovery codes, plus passkeys (WebAuthn), are available today; an organization can require MFA for its users, enforced by the platform before business APIs are reachable.

Integration with an organization's existing identity provider for centralized authentication.

Users are assigned roles that determine what they can view, create, modify, and approve within The Forge. Standard roles include owner, manager, employee, and contractor. Authorization is fail-closed — an unrecognized role is denied even where broad access is configured.

Permissions can be scoped so a location manager sees only their assigned location and a business administrator sees only their assigned business.

Administrative actions such as user creation, role changes, and integration configuration require appropriate administrative authority and are recorded in the activity history.

Multiple legal businesses or companies can be managed under one account, with access boundaries that stop a user assigned to one business from seeing another business's records without authorization.

Users can be assigned to specific operating locations so they see only the records, schedules, and reporting relevant to their assigned location.

Authorized executives can view reporting across multiple businesses and locations without giving every user the same cross-organization access.

Every read and write in the platform passes through a single data-access layer that enforces the requesting organization's identity, so one customer's users cannot reach another customer's records. This boundary is exercised by 17 dedicated isolation test suites.

All data transmitted between the browser and The Forge is encrypted using HTTPS with TLS, enforced by the hosting infrastructure.

Customer data stored in the platform database is encrypted at rest by the hosting provider's storage infrastructure.

Platform secrets live in the hosting platform's secret store, never in source or plain configuration; integration credentials stored in the database are encrypted (AES-256-GCM); an automated secret-scanning gate runs in the development pipeline.

Every API endpoint validates inputs with strict size caps and enumerated values, and user-submitted content is sanitized before storage and display to prevent injection attacks. A fail-closed content-safety gate reviews any platform-generated outbound text.

Each integration must be explicitly authorized by an account administrator before it can access or modify customer data.

Integrations are configured with specific permissions that define which data they can read and which actions they can perform.

Account administrators can disconnect an integration and revoke its access at any time. Revocation permanently disables the connection and wipes stored credentials.

Actions above a configured dollar amount or sensitivity level can require owner or manager approval before they execute.

Authorized administrators can stop all optional purchasing activity when immediate intervention is required.

No optional campaign, lead purchase, subscription expansion, or external service is activated without the configured customer approval. Monthly caps, category limits, and approval workflows are configurable.

User creation, permission changes, integration changes, and administrative actions are recorded in an append-only (insert-only) audit table with actor, timestamp, and before/after detail.

Failed sign-in attempts are tracked as aggregate counters that drive account lockout, and lockout events are recorded in the audit history for review by account administrators.

Changes to customer records, workflow configurations, and approval decisions are recorded with the actor and timestamp.

Runtime observability is enabled with full request sampling, and the platform exposes a liveness health endpoint. Degradations are detected and addressed by the operations team.

Runtime errors and failed requests are captured through the hosting platform's observability pipeline and structured telemetry; free-text content is stripped from telemetry events by design.

A per-connection health view, an error queue with retry/resolve/discard, and real outbound connectivity tests for supported providers.

The platform application instructs browsers to report any blocked content-injection attempt to a reporting endpoint, so policy violations are observable rather than silent.

Platform databases are backed up according to the hosting provider's backup schedule. Backups are used for disaster recovery, not for individual record-level restoration on demand.

Failed or problematic deployments can be rolled back to restore the previous working version of the platform.

Recovery procedures are tested to verify that platform data and operations can be restored after an incident.

Critical actions carry idempotency keys so retries and double-clicks cannot double-apply an operation, and side effects are queued through a transactional outbox so they are delivered reliably or surfaced as failures — never silently lost.

All platform code is maintained in version control with a code review process before changes are merged.

Third-party dependencies are tracked, reviewed for known vulnerabilities, and updated as part of the development process.

Development, staging, and production environments are separated so that changes are tested before reaching the production platform.

Independent security testing of the platform by a qualified external party.

Platform updates are applied centrally by HustleForge. Customers do not need to install updates on their devices or manage separate software versions.

Updates go through development, review, testing, and staging before reaching the production environment.

A defined process for detecting, assessing, containing, and resolving security events, including customer notification where required.

A contact method for reporting security vulnerabilities discovered in The Forge, with an expected acknowledgment process, published at a canonical RFC 9116 security.txt file (https://www.theforge.systems/.well-known/security.txt).

The customer controls which users have access, what roles they hold, and when access is removed. HustleForge provides the access-control capabilities.

The customer is responsible for the security of the devices and browsers used to access The Forge. HustleForge secures the platform application.

Authorized users can export customer-supplied records from The Forge in supported formats. Full-organization export requires owner authority with a second authorization check; exports exclude platform security internals and redact credential material.

Retention settings are configurable per record type. Account offboarding requires typed confirmation and password re-verification, includes a 7-day cancellation grace period, then permanent deletion in dependency-safe order.

Customer-supplied data remains the property of the customer organization. HustleForge does not sell, share, or use customer data for purposes outside the scope of operating The Forge.