Security at Indus Emissary

HTTPS is enforced for all traffic to indusemissary.com (HTTP requests are automatically redirected to HTTPS), and modern TLS is enforced at the network edge. HTTP Strict Transport Security (HSTS) is enabled with a 6-month policy duration. We have not yet extended this policy to all subdomains or submitted to browser HSTS preload lists — we are validating subdomain HTTPS coverage first before doing so, since both of those settings are difficult to safely reverse once applied broadly.

The database and file storage are provided as a managed service and are encrypted at rest by the hosting platform using platform-managed keys. We deliberately do not name a specific cipher or key length here, because that is a platform guarantee we cannot independently verify from our own codebase.

Password hashing and its work factor are managed by our authentication provider, not configured directly by us. Email one-time codes are never stored in readable form — they are kept as keyed HMAC-SHA256 digests, are single-use, expire after ten minutes, and are rate limited per email address and per network address with progressive back-off. Time-based one-time password multi-factor authentication is mandatory for all internal staff accounts: an administrator or consultant cannot reach the internal workspace without an enrolled authenticator and a second factor completed in the current session. Multi-factor authentication is available and encouraged, but not forced, for candidate and partner accounts.

Row-level security is enabled on every table in the application database, including case and application records, uploaded documents and their version history, and candidate–consultant messaging. Policies scope each row to the signed-in user's identity and role, so candidates see only their own case, partners see only cases assigned to them, and internal notes and audit records are restricted to staff roles. Privileged role changes are restricted to super administrators, enforced in the database itself and recorded in the audit trail.

Application-level rate limiting is enforced server-side on candidate sign-in, partner sign-in, staff sign-in, password reset, one-time code request and verification, the contact form, privacy requests and new application submissions. Limits are applied per network address and, for code flows, per email address, with progressive back-off on repeated attempts. Network addresses are stored only as salted hashes, never in raw form.

Security-relevant events are written to an append-only audit log that cannot be edited or deleted from the application, including by administrators. Coverage includes failed sign-in attempts, attempts to use an account on the wrong portal, role grants and revocations, application and case changes, document uploads, replacements and downloads, partner approvals, and privacy or data-subject access activity. Sensitive values are masked and identifiers such as network addresses are hashed before storage.

Uploads are validated server-side by inspecting the file's actual content signature rather than trusting its name or declared type, are scanned before being accepted, and are served only through short-lived signed links to roles permitted to see them. Approved documents are locked against replacement at the database level, and full version history is retained for staff review.

Automated dependency vulnerability scanning is enabled on our codebase (GitHub Dependabot), including active security alerts and scheduled version-update pull requests reviewed on a regular cadence.

We run custom security rules at the network edge (Cloudflare) that block known exploit-probe paths, malicious scanner user agents, and direct access attempts to internal service routes, before traffic reaches our application. We also run edge-level rate limiting on all authentication endpoints (candidate sign-in, partner sign-in, staff sign-in, password reset), independent of the rate limiting enforced in our own application code.

Network-layer, SSL/TLS-layer, and HTTP-layer DDoS mitigation is active at the network edge (Cloudflare), automatically detecting and mitigating volumetric and protocol-based attacks.

A managed web application firewall ruleset (covering broader attack patterns such as SQL injection and known CVEs) requires a plan upgrade we have not yet completed. In the meantime, custom edge security rules and rate limiting (above) provide an initial layer of protection.

We publish a machine-readable security contact and welcome good-faith vulnerability reports. We aim to acknowledge and act on reports promptly, and we ask researchers to give us reasonable time to investigate before public disclosure. We have not yet adopted a formal disclosure policy with committed response and remediation windows, so we do not state specific timeframes here — we would rather publish them once we know we can meet them every time.