Security Disclosure Policy

I'm Chris - an IT infrastructure engineer who has spent 25+ years telling other people to patch their systems, rotate their secrets, and stop using admin/admin as credentials. If you've found a security issue on this site, I genuinely want to hear about it. The fact that this is a personal blog doesn't mean the people who visit it deserve less protection.

This page explains how to report a vulnerability responsibly, what I'll do with it, and what you can expect from me in return. Short version: report it, I'll fix it, I'll thank you, nobody gets sued. Long version: read on.

Scope - What I Want to Know About

If you find any of the following on chrisbmn.com or its subdomains (*.chrisbmn.com), please report it:

Cross-site scripting (XSS) - reflected, stored, or DOM-based
SQL injection - or any other injection that touches the database
Authentication or session issues - bypassing login, session fixation, token leakage
Unauthorized data access - being able to read data that isn't yours
Server-side request forgery (SSRF)
Significant misconfigurations - exposed credentials, open directories containing sensitive files, that sort of thing
Anything that surprised you - if your gut says "I probably shouldn't be able to do this," it's worth reporting

The site includes a blog, contact form, comment system, admin panel, and a handful of subdomains. All of it is in scope unless otherwise noted below.

Out of Scope - What I Don't Need to Hear About

To keep things focused on issues that actually matter, the following are out of scope:

Denial of service attacks - DO NOT hammer my site. That is not research, it isn't clever, and it will not impress me. It's just plain rude.
Brute-force or rate-limit testing - I have rate limiting in place; testing it by actually brute-forcing isn't necessary.
Social engineering - attempting to trick me into revealing information doesn't count as a technical vulnerability.
Vulnerabilities in third-party services - if Google, BunnyCDN, MDDHosting, or Namecheap has a problem, report it to them directly. I can't fix their infrastructure.
Missing "nice to have" headers - if a scanner flagged something theoretical with no realistic attack path, it's probably already on my radar.
Email best practice suggestions - my DMARC record is already judging outbound mail more harshly than you are. (Probably.)
Self-XSS - if the attack requires you to paste code into your own browser console, that's not a vulnerability, that's a personality trait.
Physical access attacks - if you're at my desk, we have bigger problems than a web vulnerability.

How to Report

Email security@chrisbmn.com - subject line "Found Security Issue" works fine. Please include:

A clear description of the vulnerability and its potential impact
The URL or component where you found it
Steps to reproduce - the more precise, the faster I can confirm and fix it
Any supporting evidence: screenshots, proof-of-concept code, request/response captures
Your preferred name or handle for acknowledgment (or let me know if you'd prefer to stay anonymous)

You can also reference my security.txt for the canonical machine-readable version of this contact information.

Please don't file public bug reports, open GitHub issues, or post about it on social media before I've had a chance to fix it - I take this seriously, and you'll see that in how I respond.

What Happens After You Report

Here's what you can expect once I receive your report:

Acknowledgment - I'll confirm I received your report within 48 hours, usually sooner. If you don't hear back, check your spam folder and try again.
Triage - I'll investigate, reproduce the issue, and assess severity. I'll keep you updated.
Fix - For critical issues, I'll prioritize a fix immediately. For lower-severity issues, I'll work through them in a reasonable timeframe and let you know when it's patched.
Disclosure - Once the fix is deployed, I'm happy to discuss public disclosure. I'll coordinate the timing with you.

I'm running this as a one-person operation and as a hobby. I don't have a security team, a ticketing system, or a dedicated on-call rotation. What I do have is a genuine interest in keeping things secure and a habit of actually responding to email.

Safe Harbor

If you discover and report a vulnerability in good faith - meaning you're not exfiltrating data, not defacing the site, not publishing exploit code before I've had a chance to respond, and generally acting like a decent person - I will not pursue legal action against you. Not even a strongly worded letter.

This is a personal site. I have no interest in involving lawyers over a responsibly disclosed bug. I have significant interest in not having a vulnerable site. These goals align perfectly.

Bug Bounty

I wish I could offer a cash bounty - I genuinely do. But this is a personal blog on a shared hosting plan, not a tech company with a security budget. What I can offer:

A genuine, personal thank-you
Public acknowledgment on this page (with your permission - some people prefer the quiet satisfaction of having done a good thing)
The warm knowledge that you made the internet marginally more secure for the handful of people who actually visit here

It's not cash. But it's real, and it comes from the heart from someone who actually appreciates it.

Acknowledgments

The following people have responsibly disclosed security issues to chrisbmn.com. Thank you - this stuff matters.

Nobody yet - but there's always a first.

Questions

If anything here is unclear, or you want to ask whether something falls in scope before digging into it, just ask: admin@chrisbmn.com or the contact form. I'll give you a straight answer.