1. Scope
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.
2. Protecting the public website
- HTTPS: the site is delivered over encrypted connections and sends HTTP Strict Transport Security instructions to compatible browsers.
- Browser controls: security headers restrict framing and resource loading, prevent content-type sniffing, and limit permissions such as camera, microphone and location access.
- Server-side credentials: contact-email credentials are used by the server endpoint rather than included in public page code.
- Delivery: Cloudflare provides the public site’s hosting and delivery infrastructure.
These controls reduce particular risks; they are not a claim of end-to-end encryption or a security certification.
3. Contact-form safeguards
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.
4. Protect your account and information
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.
5. Report a security concern
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.
- The affected website address or product.
- A concise description of the issue and its possible impact.
- Steps to reproduce it using your own account or test data, if available.
- The approximate date and time you observed it.
- A way for the team to contact you.
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.
6. Responsible reporting
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.
7. Review and response
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.
8. Incident information and limits
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.
9. Related policies and updates
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.