Outcron Plain HTML

Security

Controls built for teams running real operational workloads.

Outcron is designed for teams that need external scheduling and execution without giving up core security expectations. The hosted platform combines encrypted secrets, scoped access, strong sign-in options, and traceable run history in one place.

AES-256-GCM encryption at rest

Sensitive fields — credentials, secrets, configuration values — are encrypted with AES-256-GCM before they reach the database. Keys are derived via HKDF-SHA256 with per-field random salts, so compromising storage alone does not expose secret data.

TLS 1.2+ in transit, HSTS enforced

All traffic is encrypted with a TLS 1.2 minimum. HSTS headers (max-age one year, includeSubDomains) tell browsers to always use HTTPS. Outbound HTTP connections made by job executors enforce the same TLS floor.

Passwords, TOTP, passkeys, and scoped API keys

Passwords are hashed with bcrypt. Accounts support TOTP two-factor authentication with ten bcrypt-hashed recovery codes, plus WebAuthn passkey login that bypasses password and TOTP entirely. API keys use a 128-bit random secret, SHA-256 digested at rest (legacy bcrypt accepted transparently), with org-scoped permission tags.

Container isolation and SSRF protection

Container jobs run with all Linux capabilities dropped, no-new-privileges, a read-only root filesystem, PID/memory/CPU limits, non-root UID 65534, and an isolated bridge network with iptables rules blocking metadata endpoints and private ranges. HTTP job requests are validated at dial time to block loopback, RFC 1918, and link-local addresses.

Org-scoped role-based access control

Each organization is fully isolated. Access resolves through roles, groups, and granular permission tags. The same permission catalog governs both user sessions and API keys.

Auditable execution history

Every mutation is audit-logged with actor, action, field-level diffs, request ID, and client IP. Sensitive fields are redacted from log projections. Execution snapshots are captured at run time so operators can inspect what happened without relying on mutable live state.

Defense in depth

Sensitive values are protected in layers. Credentials and secrets are encrypted with AES-256-GCM using HKDF-SHA256-derived keys before they are written to the database — not just disk-level encryption.

Authentication is multi-layered: bcrypt password hashing, time-based one-time passwords (TOTP) with ten single-use bcrypt-hashed recovery codes, and WebAuthn discoverable passkeys. Login attempts are rate-limited (five failures trigger a 15-minute lockout). Purpose-scoped JWTs prevent token reuse across flows, and sessions are invalidated immediately on email or password change.

Container jobs execute in hardened sandboxes: all Linux capabilities dropped, privilege escalation blocked, read-only root filesystem, 256-PID limit, memory and CPU caps, non-root user, and an isolated network with iptables rules that block cloud metadata endpoints and private IP ranges. HTTP jobs use a SSRF-safe client that validates resolved IPs at dial time against loopback, RFC 1918, and link-local ranges.

API rate limiting uses the GCRA algorithm for cross-instance consistency. Every API mutation is audit-logged with field-level diffs, request IDs, and client IPs — sensitive fields are automatically redacted.

Need a deeper review?

If your team needs a security conversation before onboarding, use the contact page to ask about deployment posture, authentication controls, encryption behavior, or execution-isolation expectations.

The right starting point depends on whether you are evaluating hosted operations, API automation, or container execution for internal workloads.

Contact Us