Public website safeguards
HTTPS, browser security controls and server-side contact-email credentials help protect the public website.
Read the controlsLEX / SECURITY
Understand the safeguards on our public website, the scope of our policy and how to raise a concern.
These safeguards apply to the AskLex public website. For Chambers or Translate workspace and document requirements, ask for service-specific information.
HTTPS, browser security controls and server-side contact-email credentials help protect the public website.
Read the controlsContact forms use server-side checks and submission limits. Read how information is handled before sending a message.
Read the privacy policyTell the team about a suspected issue using a safe, concise description. Do not include passwords or confidential client files.
How to reportTHE DETAIL
Last updated: 28 September 2026
This policy describes security measures verified for the AskLex public website at asklex.law and its lex.lk redirects. It also explains how to report a suspected security issue to the AskLex team.
It does not certify the security of every linked product, establish a service-level agreement, or guarantee that a service is free from vulnerabilities. For account, document or workspace security requirements in Chambers or Lex Translate, ask the team for the information relevant to that service before relying on it.
These controls reduce particular risks; they are not a claim of end-to-end encryption or a security certification.
Support and callback submissions are checked on the server for field length, format and request size. The endpoint checks the request origin, uses a spam-trap field and applies submission limits. The receiving support address is configured on the server rather than accepted from the visitor.
Form messages are delivered by email through Resend. Email correspondence is not an appropriate place for passwords, secret keys or complete confidential files. Read the Privacy Policy for information about processing and retention.
Use a unique password for account-based services and any additional authentication options the service offers. Keep your browser and device updated, check the website address before signing in, and sign out when using a shared device.
Do not share credentials with colleagues or send them to support. If you believe an account or credential has been exposed, change or revoke the affected credential through the relevant service and contact the team. Include only the information needed to identify the issue.
Email [email protected] with “Security report” in the subject. This is the published contact for reporting suspected vulnerabilities; it is not an emergency-response service.
Redact client information, session tokens, passwords and other secrets from screenshots or logs. If evidence is sensitive, send a brief description first and ask the team how to share it securely.
Stop testing if you encounter another person’s information or risk disrupting a service. Do not access, copy, alter or delete data belonging to others, bypass account permissions, conduct denial-of-service tests, use social engineering, or publish sensitive evidence.
This page invites reports of issues you observe; it does not grant permission for intrusive testing or establish a bug-bounty reward. Obtain written authorisation before carrying out testing beyond normal, authorised use.
Reports are received through the support mailbox so the team can assess the affected service and appropriate next steps. We may ask for clarification or a safe reproduction example. Keep any follow-up in the same email thread where possible.
We do not publish a guaranteed acknowledgement or resolution time. If you have not received a response, follow up through the contact page without including sensitive evidence in a public channel.
If you suspect a data exposure, tell the team which service and information may be affected. Avoid circulating exposed material. The handling of an incident depends on its facts, the service involved and applicable notification obligations.
Nothing on this page should be read as a promise of uninterrupted availability, zero breaches, a specific recovery time, or an independently audited security standard.
See the Privacy Policy for information handling and the Terms of Service for use of the service. The date above identifies the current version of this security policy.
Security researchers can also find our reporting contact at security.txt.