Security Policy

The most secure way to protect sensitive calculation data is to never receive it. This document explains how that principle is implemented and enforced across ApexConverter.

1. Security Model Overview

Conventional web applications collect user input, transmit it to a server, process it, and return a result. Each stage in that chain introduces attack surface: interception in transit, compromise at rest, insider access, vendor exposure, and legal compulsion.

ApexConverter eliminates the chain entirely for calculation data. Our threat model treats every input as potentially sensitive — a salary, a debt balance, a medical measurement, a proprietary engineering tolerance — and responds with the only control that cannot fail: we never receive it.

2. Zero-Server Client-Side Execution

Each calculator ships as static HTML with an inline JavaScript engine. On page load the browser parses that engine and binds it to the form. Every keystroke triggers a local function call operating on in-memory values. Results are written directly to the DOM.

This is a verifiable claim, not a promise. Disconnect your device from the network after a tool page loads and the calculator will continue to operate at full capability.

3. Transport Security

• TLS 1.3 exclusively, with TLS 1.0 and 1.1 disabled and only forward-secret cipher suites enabled.
• HTTP Strict Transport Security with a two-year max-age, subdomain inclusion, and preload registration.
• Automatic upgrade of any plain-HTTP request via permanent redirect.
• Certificate Transparency logging on all issued certificates, with automated expiry monitoring.

4. Application Hardening Headers

5. Infrastructure & Access Control

Static assets are served from a globally distributed edge network with origin shielding and automated DDoS mitigation. The origin holds no user data of any kind.

• Administrative access requires hardware-backed multi-factor authentication with no SMS fallback.
• Deployment is exclusively through signed, reviewed commits to version control; direct production edits are technically prohibited.
• Access follows least privilege, with quarterly recertification of every account.
• Dependency and supply-chain scanning runs on every build; the site's runtime dependency count is deliberately zero.

6. Advertising & Third-Party Code

The platform is funded by contextual display advertising. We hold advertising partners to constraints designed to protect the core guarantee:

• Ad scripts are loaded asynchronously and are never present in the critical rendering path.
• Advertising code has no access to calculator form values; inputs are not written to any global variable, data layer, or dataset attribute readable by third parties.
• Partners are contractually barred from attempting to read form content or inject additional trackers.
• Ad slots are dimensioned in advance to prevent layout shift and to constrain injected markup.

7. Vulnerability Disclosure

We welcome good-faith security research and commit to handling reports professionally.

Safe harbour. We will not pursue action against researchers who act in good faith, avoid privacy violations and service degradation, do not access or modify data belonging to others, and allow reasonable time for remediation before public disclosure.

Please include: affected URL, reproduction steps, observed and expected behaviour, and any proof-of-concept. Please exclude automated scanner output without manual validation, and issues that require a fully compromised end-user device.

8. Incident Response

Should a security incident occur, we operate a documented four-phase response: contain, assess, remediate, and disclose. Because we hold no calculation data, the realistic incident scope is limited to site availability or content integrity. Any incident materially affecting users will be published on this page with a timeline, root-cause analysis, and the corrective actions taken.