Security & Compliance Report
Security Overview
Comprehensive security controls and compliance readiness documentation for the Slopshop API platform. Built for enterprise adoption — authentication, data protection, audit logging, incident response, and cryptographic verification on every response.
SOC 2 TYPE II — IN PREPARATION (NOT YET CERTIFIED)
We are working toward SOC 2 certification. This page documents our current security controls, not a certification status.
01
Infrastructure Security
The Slopshop API enforces transport-layer security, security headers, origin controls, and request limits at the application and network edge. The server handles graceful shutdown to prevent data loss during deployments.
HTTPS enforced in production (301 redirect)
All traffic to
slopshop.gg is served over TLS 1.3. HTTP requests
receive a 301 permanent redirect to HTTPS. The API proxy and edge
CDN both enforce TLS termination before traffic reaches the application layer.
Railway Pro + Vercel edge enforce HTTPS; app.set('trust proxy', 1)
Content Security Policy (CSP) enabled
CSP headers restrict script sources, frame ancestors, and object sources to
prevent cross-site scripting (XSS) and injection attacks. Inline scripts are
restricted to the application's own origin.
Enforced at the edge layer; API responses include CSP headers
Helmet.js security headers
Helmet is applied as the first Express middleware, setting
X-Frame-Options, X-Content-Type-Options: nosniff,
Strict-Transport-Security, X-DNS-Prefetch-Control,
X-XSS-Protection, and Referrer-Policy on every response.
server-v2.js: app.use(helmet({ ... })) — first middleware in chain
CORS: Access-Control-Allow-Origin: * (public API)
CORS: Access-Control-Allow-Origin: * (public API — standard for REST APIs like Stripe and Twilio). Configurable via
CORS_ORIGIN environment variable for self-hosted deployments.
server-v2.js: cors({ origin: process.env.CORS_ORIGIN || '*' })
Request body size limits per endpoint type
Express is configured to reject oversized payloads. Standard API endpoints enforce
a 1 MB body limit. Batch and army endpoints allow larger payloads
as needed, but each has an explicit upper bound. This prevents memory exhaustion
before any application logic runs.
server-v2.js: express.json({ limit: '1mb' }) — per-route overrides for batch
Graceful shutdown on SIGTERM/SIGINT
The server listens for
SIGTERM and SIGINT signals and
performs a graceful shutdown: stops accepting new connections, waits for in-flight
requests to complete, flushes SQLite WAL, and then exits cleanly. This prevents
data loss during container restarts or deployments.
server-v2.js: process.on('SIGTERM', gracefulShutdown)
02
Authentication & Authorization
All API calls require a bearer token. Passwords and API keys are never stored in plaintext. Key scoping, rate limiting, and timing-safe comparisons protect against brute force and side-channel attacks.
API keys with PBKDF2 hashing (100K iterations, SHA-512)
User passwords are hashed with
crypto.pbkdf2Sync using SHA-512,
100,000 iterations, and a 16-byte random salt generated with
crypto.randomBytes(16). The salt is stored alongside the derived
key; the plaintext password is never persisted, logged, or returned in any response.
auth.js: crypto.pbkdf2Sync(password, salt, 100000, 64, 'sha512')
Scoped keys with per-tier/per-category restrictions
API keys can be scoped to specific tiers (free, pro, enterprise) and API categories.
A scoped key can only access endpoints within its allowed categories, enforcing
least-privilege access. Team-level keys with per-namespace isolation are supported.
server-v2.js: key scope validation in auth middleware — rejects out-of-scope calls
Timing-safe secret comparisons (crypto.timingSafeEqual)
All secret comparisons (API key validation, admin secret checks, HMAC verification)
use
crypto.timingSafeEqual to prevent timing side-channel attacks.
This ensures that the comparison time does not leak information about the secret
value, even to an attacker measuring response latency.
server-v2.js: crypto.timingSafeEqual(Buffer.from(a), Buffer.from(b))
Rate limiting per key (60 req/min default, configurable)
Every API key is subject to rate limiting. The default limit is 60 requests
per minute, configurable per tier (enterprise keys receive higher limits).
Signup is limited to 5 requests/hour/IP; login is limited to 10 requests/minute/IP.
Rate limit state is cleaned up every 5 minutes to prevent unbounded memory growth.
server-v2.js: rateLimit per key + per IP; configurable via tier settings
Retry-After headers on 429 responses
When a rate limit is exceeded, the server returns HTTP 429 with a
Retry-After header indicating the number of seconds until the
limit resets. This enables well-behaved clients to back off automatically
without hammering the API.
res.set('Retry-After', secondsUntilReset) on HTTP 429
API key rotation
Users can rotate their API key at any time via
POST /v1/auth/rotate-key.
The old key is immediately invalidated and the full credit balance transfers to the
new key. Both the in-memory cache and the SQLite database are updated atomically.
auth.js: /v1/auth/rotate-key — old key deleted from apiKeys Map and DB
03
Data Protection
Data in transit is encrypted via TLS. Persistent storage uses SQLite with WAL journaling for crash safety. Memory is isolated per API key, and every response includes a SHA-256 output hash for tamper detection.
Memory isolation per API key (16-char SHA-256 prefix)
Each API key's persistent memory is stored in an isolated namespace derived from
a 16-character SHA-256 prefix of the key. One key cannot read,
write, or enumerate another key's memory entries. This provides strong tenant
isolation at the data layer without requiring separate databases.
server-v2.js: namespace = sha256(apiKey).slice(0, 16) — used as memory partition key
SQLite WAL mode for crash-safe writes
The database is opened with
journal_mode = WAL (Write-Ahead Logging),
which provides crash recovery and allows concurrent reads. If the process is
interrupted mid-write, WAL ensures the database returns to its last consistent
state on next open. No data corruption occurs from unclean shutdowns.
server-v2.js: db.pragma('journal_mode = WAL')
Credit refund on handler errors
If an API handler throws an unrecoverable error after credits have been deducted,
the credits are refunded automatically before the error response
is sent. Users are never charged for failed executions. The refund is persisted
to SQLite immediately.
server-v2.js: catch block refunds credits and persists balance on handler error
No plaintext password storage (PBKDF2)
The
users table stores only the PBKDF2-derived hash and the random
salt. The plaintext password is never written to disk, logged, or returned in any
API response. API keys in the database are also hashed.
users table schema: password_hash TEXT, salt TEXT — no password column
Output hash verification (SHA-256) on every response
Every API response body includes an
_output_hash field containing
the SHA-256 digest of the response payload. Clients can independently verify that
the response has not been tampered with in transit or by a proxy. This is included
on every single API call automatically.
server-v2.js: _output_hash = sha256(JSON.stringify(result))
Parameterized SQL queries — no SQL injection
All database access uses better-sqlite3's
db.prepare() with positional
parameters. User-supplied values are bound at execution time — they are never
interpolated into SQL strings. This eliminates the entire class of SQL injection
vulnerabilities across all queries.
server-v2.js: db.prepare('SELECT * FROM api_keys WHERE key = ?').get(key)
04
Audit & Observability
Every authenticated API call produces a structured audit record. Response headers provide per-call telemetry. All activity is correlatable via request IDs and traceable via API versioning.
Structured JSON logging with timestamps
All server logs are emitted as structured JSON with ISO-8601 timestamps,
log levels, and contextual metadata (request ID, key prefix, endpoint, latency).
This format is compatible with log aggregation systems like Datadog, Splunk,
and CloudWatch for centralized monitoring.
Structured log format: { ts, level, requestId, keyPrefix, endpoint, latencyMs, ... }
X-Request-Id on every response (correlatable)
Every API response includes an
X-Request-Id header containing a
unique identifier for that request. This ID is also recorded in the audit log,
enabling end-to-end correlation between client-side logs and server-side records
for debugging and compliance investigations.
res.set('X-Request-Id', crypto.randomUUID())
X-API-Version header for change tracking
Every response includes an
X-API-Version header indicating the
server version that produced the response. This enables clients to detect API
changes, supports rollback verification, and provides an audit trail of which
code version handled each request.
res.set('X-API-Version', SERVER_VERSION)
Audit log of every API call
Every API execution writes a row to the
audit_log table containing:
timestamp, key prefix (not the full key),
API endpoint, credits consumed,
latency in milliseconds, and the execution engine.
Indexes on ts and api support efficient queries.
Users can query their own history via GET /v1/usage.
audit_log schema: ts, key_prefix, api, credits, latency_ms, engine — indexed on ts, api
Sunset/Deprecation headers for future API changes
When APIs are scheduled for deprecation, the server includes
Sunset
and Deprecation headers per RFC 8594 and the IETF Deprecation
header draft. This gives clients advance notice of breaking changes and enables
automated migration tooling.
res.set('Sunset', 'date') / res.set('Deprecation', 'true') on deprecated endpoints
Per-call telemetry headers
Every API response includes
X-Credits-Used,
X-Credits-Remaining, X-Latency-Ms,
X-Request-Id, and X-Engine headers. This allows
clients to observe their consumption in real time without querying the usage
endpoint.
res.set('X-Credits-Used', ...) / res.set('X-Credits-Remaining', ...)
05
Compliance Readiness
Slopshop is working toward SOC 2 Type II certification but is not yet certified. We implement controls aligned with enterprise compliance requirements. The platform is designed to be self-hostable for air-gapped and regulated environments.
SOC 2 Type II — In Preparation (Not Yet Certified)
- SOC 2 Type II certification has not been completed. We are implementing controls for security, availability, and confidentiality trust service criteria at the application layer. Formal audit with an independent assessor is planned but not yet scheduled.
-
Self-hostable for air-gapped/compliance deployments. The entire
platform can be deployed on-premises with
npm install slopshop && node server-v2.js. All compute APIs run with zero external dependencies. Enterprise customers can audit, modify, and deploy in fully isolated environments. -
/.well-known/security.txtendpoint. A machine-readable security contact file is served at the standard well-known URI per RFC 9116, providing vulnerability disclosure contacts and policy links. - No tracking, no analytics, no third-party scripts on API. The API server does not include any tracking pixels, analytics scripts, or third-party JavaScript. No user data is shared with advertising or analytics providers. The only outbound connections are to explicitly configured upstream APIs (LLM providers, when enabled).
-
GDPR: data deletion available via memory-delete. Users can delete
all their persistent memory data via the
memory-deleteAPI. Account deletion is available on request. No data is retained after deletion beyond the audit log (which contains only anonymized key prefixes, not personal data). - security.txt contact: dev@slopshop.gg
Service Level
Uptime Target: 99.5%
Slopshop targets 99.5% uptime for the hosted API. The API runs on Railway Pro with automatic TLS, health monitoring, and zero-downtime deploys. Compute-tier APIs (189 endpoints) have zero external dependencies and are the most reliable. Network and LLM APIs depend on upstream providers.
For guaranteed SLAs with contractual commitments, contact dev@slopshop.gg for enterprise plans.
06
Incident Response
Slopshop maintains an incident response process for security vulnerabilities, service outages, and data incidents.
Reporting a Security Vulnerability
- Contact: dev@slopshop.gg
- Response time target: less than 24 hours for initial acknowledgment
- Status page: slopshop.gg/status-page
- Disclosure policy: We follow coordinated disclosure. We will work with reporters to understand and resolve issues before any public disclosure.
- Scope: All slopshop.gg infrastructure, API endpoints, client libraries, and documentation sites are in scope for vulnerability reports.
Incident classification and escalation
Incidents are classified by severity (P0 through P3). P0 incidents (data breach,
complete service outage) trigger immediate response. P1 incidents (partial outage,
security vulnerability) are addressed within 4 hours. All incidents are documented
with root cause analysis and remediation steps.
Post-incident review process
Every P0 and P1 incident results in a written post-mortem documenting the timeline,
root cause, impact, and remediation. Lessons learned are incorporated into the
engineering roadmap to prevent recurrence.
07
Verification
Slopshop provides cryptographic proof of execution on every response. Clients can independently verify that results are authentic, untampered, and produced by the real execution engine.
Every response includes _engine: "real" execution proof
Every API response body contains an
_engine field confirming the
execution backend. For compute APIs, this is always "real", indicating
the handler executed genuine computation rather than returning cached or mock data.
This field is verifiable via self-hosting.
response._engine = "real" — included on every compute API response
SHA-256 output hashes for tamper detection
Every response includes an
_output_hash field containing the SHA-256
digest of the result payload. Clients can recompute
sha256(JSON.stringify(result)) to verify that neither a proxy, CDN,
nor man-in-the-middle has modified the response content.
_output_hash = crypto.createHash('sha256').update(payload).digest('hex')
Merkle proofs for batch/army operations
Batch and army (parallel compute) endpoints return a Merkle root
computed from the individual result hashes. This allows clients to verify the
integrity of the entire batch result set with a single hash comparison, and to
prove the inclusion of any individual result within the batch.
batch._merkle_root = merkle(results.map(r => r._output_hash))
Self-host to verify
The entire Slopshop platform is available as an npm package. Enterprise customers
and security auditors can run the exact same server locally, submit the same inputs,
and verify that the outputs and hashes match the hosted API. This provides the
strongest possible verification guarantee.
npm install slopshop && node server-v2.js — identical compute handlers
TEE attestation on roadmap
Trusted Execution Environment (TEE) attestation is on the engineering roadmap.
This will enable cryptographic proof that compute handlers are running inside a
verified, tamper-proof enclave, providing hardware-level execution guarantees
beyond what software verification alone can provide.
Roadmap: TEE attestation via Intel SGX or AMD SEV for compute handlers
08
Control Summary
| Category | Control | Status |
|---|---|---|
| Infrastructure | HTTPS enforced (301 redirect) | IMPLEMENTED |
| Infrastructure | Content Security Policy (CSP) | IMPLEMENTED |
| Infrastructure | Helmet.js security headers | IMPLEMENTED |
| Infrastructure | CORS: Allow-Origin: * (public API, configurable via CORS_ORIGIN env var) | IMPLEMENTED |
| Infrastructure | Request body size limits | IMPLEMENTED |
| Infrastructure | Graceful shutdown (SIGTERM/SIGINT) | IMPLEMENTED |
| Auth | PBKDF2-SHA512 (100K iterations) | IMPLEMENTED |
| Auth | Scoped keys (tier/category) | IMPLEMENTED |
| Auth | Timing-safe comparisons | IMPLEMENTED |
| Auth | Rate limiting (60 req/min default) | IMPLEMENTED |
| Auth | Retry-After on 429 | IMPLEMENTED |
| Auth | API key rotation | IMPLEMENTED |
| Data | Memory isolation (SHA-256 prefix) | IMPLEMENTED |
| Data | SQLite WAL crash-safe writes | IMPLEMENTED |
| Data | Credit refund on handler error | IMPLEMENTED |
| Data | No plaintext password storage | IMPLEMENTED |
| Data | SHA-256 output hashes | IMPLEMENTED |
| Data | Parameterized SQL (no injection) | IMPLEMENTED |
| Audit | Structured JSON logging | IMPLEMENTED |
| Audit | X-Request-Id on every response | IMPLEMENTED |
| Audit | X-API-Version header | IMPLEMENTED |
| Audit | Full audit log (every call) | IMPLEMENTED |
| Audit | Sunset/Deprecation headers | IMPLEMENTED |
| Compliance | SOC 2 Type II | IN PREPARATION (NOT YET CERTIFIED) |
| Compliance | Self-hostable (air-gapped) | IMPLEMENTED |
| Compliance | /.well-known/security.txt | IMPLEMENTED |
| Compliance | No tracking/analytics on API | IMPLEMENTED |
| Compliance | GDPR data deletion | IMPLEMENTED |
| Verification | _engine execution proof | IMPLEMENTED |
| Verification | SHA-256 output hashes | IMPLEMENTED |
| Verification | Merkle proofs (batch/army) | IMPLEMENTED |
| Verification | TEE attestation | ROADMAP |
| Infrastructure | Encryption at rest | ROADMAP |
| Infrastructure | Multi-region redundancy | ROADMAP |
09
Security Contact
Email
dev@slopshop.gg
Response Time
Less than 24 hours
Status Page
slopshop.gg/status-page
Security Policy
/.well-known/security.txt
Enterprise Inquiries
For SOC 2 readiness details, BAA agreements, or custom compliance requirements, contact dev@slopshop.gg