Skip to main content

Legal

Security Policy

How to report a vulnerability to us responsibly, and the practices behind the systems we run.

Last updated 1 August 2026

1. Reporting a vulnerability

If you believe you have found a security issue in a system operated by Infolocklabs LLP, we want to hear about it. Email contact@infolocklabs.com with "Security" in the subject line.

A useful report includes:

  • The affected URL, endpoint or component.
  • A clear description of the issue and why you believe it is a security problem.
  • Steps to reproduce it, precise enough for us to follow.
  • Any supporting evidence — a request and response pair, or a screenshot.
  • Your assessment of the impact.
  • How you would like to be credited, if at all.

Please report to us privately first and give us a reasonable opportunity to remediate before any public disclosure.

2. What we commit to

  1. 01We acknowledge receipt of a report within 3 business days.
  2. 02We provide an initial assessment, including whether we consider it in scope, within 10 business days.
  3. 03We keep you informed of remediation progress on issues we accept.
  4. 04We will not pursue legal action against a researcher who acts in good faith and within the boundaries in section 3.
  5. 05We credit reporters who want to be credited, once the issue is resolved.

We do not currently operate a paid bug bounty programme. Reports are handled on a responsible-disclosure basis.

3. Testing boundaries

In good-faith testing of our own systems, please stay within these limits:

  • Do not access, modify or delete data belonging to anyone else. If you encounter personal data, stop and tell us.
  • Do not run denial-of-service, volumetric or load testing.
  • Do not use social engineering, phishing or physical intrusion against our people or premises.
  • Do not deploy malware, backdoors, persistence or any destructive technique.
  • Do not pivot from an initial finding into other systems.
  • Use only your own test accounts and test data.
  • Do not publish details of an unresolved issue.

Systems belonging to our clients are explicitly out of scope. We have no authority to permit testing against them, and no such testing may be inferred from this policy. Report a suspected issue in a client system to that organisation directly.

4. Commonly reported items we do not treat as vulnerabilities

  • Missing security headers with no demonstrated exploit path.
  • Results from an automated scanner with no accompanying proof of impact.
  • Reports of software version numbers without a working exploit.
  • Self-XSS requiring a victim to paste content into their own console.
  • Absence of SPF, DKIM or DMARC on a domain that sends no mail.
  • Missing rate limiting on an endpoint with no sensitive effect.
  • Clickjacking on a page with no state-changing action.

5. Our security practices

At a level of detail appropriate for a public page:

  • All traffic is served over TLS, with HSTS enabled.
  • A Content Security Policy is applied with a per-request nonce.
  • Administrative access is individual, role-based and enforced server-side on every request.
  • Administrative passwords are hashed with Argon2id and are never recoverable.
  • Sessions are held in HttpOnly cookies with both an idle timeout and an absolute expiry, and only a hash of the session token is stored.
  • Sign-in is rate limited per address and per account, with a lockout after repeated failure.
  • Input is validated server-side against an explicit schema, and database access is parameterised.
  • Third-party credentials are encrypted at rest or held only in environment configuration.
  • Administrative activity is recorded in an audit log that excludes secrets.
  • Dependencies are kept current and reviewed for known vulnerabilities.

This is a summary. We do not publish detailed internal architecture, control configuration or incident procedures, because doing so would help an attacker more than it helps a researcher.

6. Data protection principles

  • We collect the minimum personal data needed for a stated purpose.
  • We retain it only as long as that purpose requires — see the Privacy Policy for periods.
  • Access is limited to those who need it for their role.
  • Data is encrypted in transit, and credentials are protected at rest.
  • Deletion requests are honoured in line with the Privacy Policy.

7. Incident handling

If we identify a security incident affecting our systems we triage and contain it, assess what data and systems were affected, remediate the cause, and notify affected parties and any relevant authority where required by applicable law. After the event we review what happened and change our controls accordingly.

8. Security contact

Security reports: contact@infolocklabs.com (subject line "Security").

Infolocklabs LLP, Gurugram, Haryana, India. Email: contact@infolocklabs.com. Phone: +91 9372406405.