Trust & Security

Apertur handles photos and metadata that often originate from your customers. We take that responsibility seriously. This page describes the controls we have in place — aligned with the OWASP Top 10, the industry-standard reference for application security risks.

Every API call and dashboard action passes through our authorization layer. Sessions are bound to a device fingerprint and rotated on suspicious activity. You can revoke any active session at any time from your account settings.

API keys are scoped per project and per environment (live vs. sandbox). Each key can be restricted by allowed IP range, allowed origin domain, and optionally by client TLS certificate. Live and sandbox keys cannot be used interchangeably.

OAuth applications validate request origins against an allowlist registered with the application — preventing token use from unauthorized domains.

Passwords are stored exclusively as bcrypt hashes with a cost factor of 12 — never in plaintext, never reversibly encrypted. API keys are stored as SHA-256 hashes and shown only once at creation.

All traffic to apertur.ca and our API is served over TLS, with HTTP Strict Transport Security (HSTS) enforced in production. Outbound webhooks must use HTTPS endpoints.

Cryptographic tokens (session IDs, password reset tokens, recovery codes) are generated using Node.js cryptographic primitives.

All inbound requests are validated against strict schemas before reaching business logic. Database access goes exclusively through a query builder with parameterized statements — no raw SQL is concatenated with user input, eliminating an entire class of SQL injection vulnerabilities.

File uploads are validated against a MIME-type allowlist, a maximum file size, and image dimension limits.

Every page response carries a Content Security Policy that locks down which scripts, styles, and connections the browser will execute or open. Inline scripts run only with a per-request cryptographic nonce; arbitrary script injection is blocked even if it bypasses output-encoding (XSS, malicious browser extension, compromised CDN). The marketing site, dashboard, and public upload page each have their own tailored policy — the upload page is the strictest, allowing only first-party scripts.

The same response also sets HSTS (transport security), frame-ancestors (prevents clickjacking via iframe), base-uri, and form-action restrictions. Policy violations are reported to our monitoring system for review.

We support multiple second factors:

• TOTP (Google Authenticator, 1Password, Authy, etc.)
• Passkeys / WebAuthn (Touch ID, Face ID, Windows Hello, hardware security keys)
• SMS one-time codes
• Recovery codes (10 single-use codes, hashed at rest)

Passwords must be at least 8 characters and are checked against the Have I Been Pwned breach corpus — known-compromised passwords are rejected at registration and at password reset.

Authentication endpoints have aggressive per-IP rate limits (5 attempts per minute on login and registration; 3 per hour on password reset). The API as a whole is rate-limited to deter enumeration and denial-of-service.

reCAPTCHA v3 scores public-facing forms (registration, login, contact). Suspicious-login detection flags anomalous IP/device patterns and triggers a security email to the account owner. Multi-account abuse signals are evaluated at registration time.

When the upload service receives a file from a contributor, it is validated, optionally watermarked or thumbnailed, and delivered directly to the destination configured for the project (S3, webhook, partner system). Originals are not retained beyond the time required for delivery — typically minutes, with a hard cap of 7 days.

Upload sessions are bound to a single-use URL. Sessions enforce expiration, a maximum image count, and per-MIME-type allowlists. End-to-end encryption can be enabled on request for sensitive workloads.

Security-relevant events are logged with timestamp, IP address, and user agent: successful and failed logins, MFA enrollment and removal, session creation and revocation, password resets, API key changes, and destination changes. Account owners can review their own audit log from the dashboard.

Application logs are structured (JSON) and retained for diagnostic and incident-response purposes.

Unhandled application errors are captured by a separate error-tracking system. Before any event is transmitted, authorization tokens, cookies, and session identifiers are stripped from request headers, request bodies for authentication and account-security routes are redacted, sensitive query parameters (`token`, `code`, `secret`, `email`, `phone`) are removed, and user context is limited to a stable account identifier — never email, name, or phone.

Apertur is hosted in Canada. Standard security headers (HSTS, secure cookie flags, cross-origin policies) are set on every response. Error responses are sanitized — stack traces and internal error details are never returned to clients. Dependencies are pinned via lockfile and reviewed before each update.

Partner-supplied logos and icons are fetched, validated, processed, and stored on our infrastructure rather than referenced at runtime. This eliminates dependency on partner-controlled servers for upload-page rendering and prevents image-host operators from observing your end-users' traffic.

We welcome reports from security researchers. If you believe you have discovered a vulnerability in Apertur, please contact us through our contact form (topic: Security) before public disclosure. We commit to acknowledging reports within 5 business days and will work with you on a coordinated disclosure timeline. We do not currently operate a paid bug bounty program, but we are happy to credit researchers in our release notes.

For security questionnaires, due-diligence requests, or to discuss a specific control in more depth, please use our contact form and select the Security topic. We respond to security inquiries within 2 business days.