Responsible Disclosure

1.Our commitment to researchers

We welcome reports from security researchers and treat them as help, not hostility. If you follow this policy in good faith, we will not pursue legal action against you, we will not ask your internet provider to identify you, and we will work with you until the issue is resolved.

If a third party brings a claim against you for activity conducted in accordance with this policy, we will make it known that your actions were authorised.

2.How to report

Email ceo@alabrishtechnologies.com with the subject "Security disclosure". Include enough detail for us to reproduce the issue: the affected URL or endpoint, the steps taken, the impact you believe it has, and any proof-of-concept code, screenshots or request captures.

Please report in English or Arabic, send the report only to us, and give us a reasonable chance to fix the issue before telling anyone else.

3.Our response

• We acknowledge every report within 2 business days.
• We give an initial assessment, including severity and whether we have reproduced it, within 5 business days.
• We aim to remediate critical issues within 7 days, high within 30 days, and others on a risk-weighted schedule.
• We keep you updated while the fix is in progress, and tell you when it ships.
• With your permission, we will credit you publicly once the issue is fixed.

4.In scope

• The website at alabrishtechnologies.ae and the ALAbrish web application.
• Our public API endpoints and webhook handlers.
• Authentication, session handling and the capability tokens used by the ALA bot assistant.
• Access-control flaws allowing one workspace to reach another's conversations, contacts or settings.
• Injection, remote code execution, server-side request forgery and deserialisation issues.
• Stored or reflected cross-site scripting with a demonstrable impact.

5.Out of scope

• Findings from automated scanners submitted without a working proof of concept or analysis of impact.
• Denial of service, volumetric load testing, or anything degrading the service for other users.
• Social engineering, phishing or physical attacks against our staff, customers or offices.
• Missing security headers, cookie flags or TLS configuration preferences with no demonstrated exploit.
• Vulnerabilities in third-party channel providers or other vendors; report those to them directly.
• Self-inflicted issues requiring a victim to paste code into a console or install a malicious extension.
• Outdated browser or operating system versions on the researcher's own device.

6.Rules of engagement

• Test only against accounts and data you own. Create a trial workspace rather than probing a real customer's.
• Stop as soon as you have confirmed a vulnerability. Do not pivot further into our systems.
• Never access, modify, exfiltrate or retain another person's data. If you encounter it accidentally, stop, do not save it, and tell us immediately.
• Do not degrade service, delete data, or lock accounts.
• Do not use a finding to extract payment. Demanding money in exchange for withholding details is extortion, not disclosure.

7.Rewards

We do not currently operate a paid bug bounty. We offer public credit, a written acknowledgement you can cite, and in cases of high impact a discretionary token of thanks. We will be straightforward with you about this rather than implying a reward that does not exist.

8.Disclosure timing

We ask for 90 days from your report before public disclosure, or until a fix has shipped, whichever comes first. If we need longer we will explain why and agree a revised date with you. We will not use the delay to avoid fixing the issue.