Security Policy

If you have found a security problem in this site, this page tells you what is in scope, what happens next, and what you can expect from me. The machine-readable version is at /.well-known/security.txt.

Scope

This policy covers baraa.sy and the application served from it. It does not cover subdomains, the hosting provider's own infrastructure, the mail provider, or any third-party service linked from the site. RFC 9116 scopes a security.txt file to the exact host that serves it, and this page keeps the same boundary.

In scope

• Remote code execution, or anything that gets you a shell.
• Injection: SQL, command, template, or otherwise.
• Cross-site scripting that survives the Content Security Policy.
• Authentication or session flaws in the admin panel.
• Access-control bypass reaching data or actions that are not public.
• Exposed secrets: credentials, keys, tokens, or environment files.

Out of scope

Not because these never matter, but because on a static-ish portfolio with no accounts and no user data they describe a risk that does not exist here, and answering them costs time that the in-scope list deserves:

• Scanner output that has not been verified by hand.
• Missing or "weak" security headers, with no attack that uses them.
• TLS configuration grades and cipher-suite preferences.
• Clickjacking on pages with no sensitive, state-changing action.
• Rate limiting, volumetric denial of service, or load testing. Please do not.
• Social engineering, phishing, or physical access.
• Missing SPF, DKIM or DMARC records on domains that send no mail.
• Anything requiring a rooted device, a malicious browser extension, or a machine already compromised.
• Self-XSS, or an issue that needs the victim to paste something into a console.

No bounty

There is no bug bounty programme and no payment for reports, in any amount, under any circumstances. Saying so plainly is the point: a request for payment before a finding is disclosed will not be answered. A genuinely useful report earns credit on this page if you want it, and my thanks either way.

Safe harbour

If you act in good faith under this policy, I will not pursue legal action against you, and if someone else does I will say publicly that your research was authorised. Good faith means all of the following:

• You stay inside the scope above.
• You access only the minimum data needed to demonstrate the issue, and you do not save, copy, or share it.
• You do not degrade the service for anyone else, and you do not modify or delete data that is not yours.
• You report promptly, and you give me a chance to fix it before telling anyone else.

Disclosure timeline

Please allow 90 days from your report before publishing it - the common industry default. If a fix lands sooner, I have no interest in keeping it quiet and you are free to publish immediately. If something takes longer, I will tell you why rather than let the clock run out in silence.

What a good report contains

• The affected URL, and the exact request that triggers it.
• Steps that reproduce the issue from a clean session.
• What an attacker gets out of it, in one sentence.
• Your name or handle, if you want the credit.

Last reviewed 2026-09-19. Related: security.txt, home.