Security Policy

How to report a security issue on this site — and what happens after you do.

Found a vulnerability? Email [email protected] with the details. I acknowledge reports on a best-effort basis within a few days. Good-faith research is welcome and won't be met with legal action.

How to report

Email [email protected] — the address listed in the security.txt file, and the only monitored channel. Please don't report exploitable issues in a public GitHub issue, since the repository is public too.

A useful report includes:

  • What you found and where
  • Steps to reproduce, or a minimal proof of concept
  • Your assessment of the impact
  • The name or handle you'd like credit under, if any

There is no PGP key at the moment. If the report is sensitive enough to need encryption, say so in your first mail and I'll arrange a secure channel.

What happens next

  1. Acknowledgement of your report, usually within five business days. This is a one-person project — there is no SLA, but reports are read and answered.
  2. Triage: I'll confirm the issue and ask questions if reproduction doesn't work.
  3. A fix, or a mitigation, shipped to the site.
  4. Coordinated disclosure. Once a fix is live you are welcome to publish your findings, with credit if you want it (or anonymously if you prefer). I'll aim to have fixes out within 90 days of a valid report; if the fix depends on a provider I don't control (Cloudflare, GitHub), I'll tell you and mitigate what I can on my side.

In scope

  • The website itself — every page served under blog.cue.my.id
  • The admin area used to write and edit posts
  • The login flow for that admin area

Out of scope

  • Denial of service, brute force, spam, social engineering, or physical attacks
  • Output of automated scanners without a validated proof of impact
  • Weaknesses in the third-party services embedded here (YouTube, X, Instagram) — report those to the provider
  • The site's source repository and account settings — report those to GitHub Security
  • Anything that requires attacking other users, degrading the service, or destroying data

Safe harbor

Good-faith security research is welcome and will not be met with legal action, as long as you: stay on the in-scope systems, avoid service degradation and data destruction, stop at proof of impact (no bulk collection or exfiltration of data), and allow reasonable time for a fix before public disclosure.

No bounty

This is a personal, unfunded blog — there is no budget for bounties. Reports earn gratitude and public credit (if wanted), not money.

Reference

Machine-readable contact details are published in a standard format (security.txt).

Last updated 2026-09-05.