Report a vulnerability in our systems

How to report

Use the report form, or email [email protected]. Include enough detail for us to reproduce the issue: the affected URL or endpoint, the steps you took, what you expected and what happened instead, and any request or response that shows it. A short proof of concept is worth more than a scanner export.

Write in English, Arabic or Dutch. If a report contains data that should not sit in a mailbox in plain text, say so in the first message and we will arrange an encrypted channel before you send it. Do not attach third-party personal data to demonstrate a finding; describe it instead.

What we commit to

• We acknowledge every report within three business days, on the Sunday to Thursday working week kept in the United Arab Emirates.
• We give you an initial assessment, including whether we consider the finding valid and an expected remediation date, within ten business days.
• We keep you informed while we fix it, and we tell you when it is closed.
• We handle your report confidentially and we do not pass your identity or contact details to a third party without your permission, unless a UAE authority compels us.
• We credit you publicly when the issue is closed, unless you would rather we did not.

Safe harbour, and its honest limits

If you follow the rules below, act in good faith and stay within the scope on this page, we will not bring a civil claim against you and we will not file a complaint with the authorities about your research. If a third party raises a complaint about testing you carried out on our systems, we will say plainly that your work was covered by this policy.

The limit is worth stating rather than hiding. Unauthorised access to information systems is a criminal matter under Federal Decree-Law No. 34 of 2021 on Countering Rumours and Cybercrimes, and offences under that law are prosecuted by the State. No private party, including us, can waive that or grant you immunity from it. What we can do is decline to complain, cooperate with you, and confirm your authorisation. Any policy that promises you more than that in this jurisdiction is overpromising.

This policy also covers only systems we control. It does not authorise you to test our suppliers, our hosting providers, or the systems of our clients, and it is not authorisation to test anything reachable from our infrastructure that we do not own.

Rules of engagement

• Access only the minimum data needed to demonstrate the issue. Stop as soon as you have shown it exists.
• Do not modify, delete, or exfiltrate data that is not yours, and do not retain any personal data you encounter. Tell us what you saw and delete your copy.
• No denial of service, load or volumetric testing, and no spam.
• No social engineering of our staff, our clients or our suppliers, and no physical attempts against our offices.
• Do not disclose the finding publicly until we have fixed it and agreed timing with you. We will not sit on a report to avoid publication.
• Do not use a finding to pivot into anything further, and do not leave persistence behind.
• One researcher, acting alone, using their own accounts. Do not test with a client's data or from a client's network.

We reserve the right to end a conversation with anyone who threatens, pressures or attempts to extort us over a report. A demand for payment in exchange for withholding a finding is not research.

Scope

In scope: redteam.ae and its subdomains, and the mail infrastructure serving those domains.

Out of scope: anything belonging to our clients, our suppliers or our hosting providers; systems reached through our infrastructure but owned by others; and any third-party service we merely link to.

What we consider a finding

Reports we will act on include remote code execution, injection into a backend system, authentication bypass, broken access control including insecure direct object references, server-side request forgery, stored or reflected cross-site scripting with a demonstrated impact, exposure of credentials or client data, and subdomain takeover.

Reports we will normally close without action, because we have already accepted the risk or because they carry no demonstrated impact: missing security headers on a page with no session; SPF, DKIM, DMARC or CAA observations; cookie flags on cookies that carry nothing; version disclosure and outdated library reports with no working exploit path; clickjacking on a page with no state-changing action; rate limiting on unauthenticated endpoints; self-XSS; and reports produced entirely by an automated scanner with no verification. If you think one of these has real impact here, show the impact and we will look again.

Recognition

This is a disclosure policy, not a paid bug bounty. We offer public credit, a written letter of appreciation you can use professionally, and, at our discretion, a reward for findings that are genuinely serious and previously unknown to us. We do not commit to a reward and we do not negotiate one in advance. If a reward is given it is final and cannot be exchanged.

For automated discovery

This policy is published at /.well-known/security.txt in the format defined by RFC 9116, so a scanner or a researcher's tooling can find the contact address without reading this page. If you would like to know how we would run a disclosure programme for you, our penetration testing service is the usual starting point.

The entity behind this document

WebSec FZCO, trading as RedTeam Security, licence number 67814, registered in the IFZA, Dubai Silicon Oasis Authority free zone. IFZA Business Park, Building A2, Nadd Hessa, Dubai Silicon Oasis, Dubai, United Arab Emirates.

Questions about this document: [email protected]. Privacy requests: [email protected]. Security reports: [email protected].