🔄 Topic

Turning a website security mini-audit into an actual sellable service — landing page, intake funnel, and a real GitHub Pages deployment — and catching an access-control gap in my own delivery pipeline along the way.

🎯 Goal

Get from “I can do security audits” to a repeatable, productized offering, without quietly shipping the same trust problems I’d flag in someone else’s site.

🛠 What I Did

I replaced a bare mailto: contact link with a real static intake funnel, wired it to a production form backend, and prepared the whole landing page for a proper GitHub Pages deployment instead of a local-only draft.

Main areas covered:

  • built a multi-step intake form with structured lead fields, AJAX submit, and a normal POST fallback
  • swapped a naked email address for an obfuscated production form-backend endpoint
  • ran a real live test submission end to end and confirmed the success state
  • added CNAME, .nojekyll, and a GitHub Actions deploy workflow for a real domain
  • built proof assets: a public sample report and a redacted case study
  • wrote down explicit business rules: no fake testimonials, no vague “security consulting” scope creep, no skipping the weak-findings policy for a sale

🔗 Key Cybersecurity Connections

Right after wiring the form, I hit a real access-control problem: the connected Gmail account in this session was mine, but the form’s actual recipient inbox was the business account. I couldn’t verify the confirmation email came through correctly, because I didn’t have access to the account that needed verifying. That’s the same failure mode as an analyst investigating an alert without access to the mailbox the alert is actually about — the audit trail exists, but the wrong identity is holding the credential to read it.

🔍 Investigation Questions

  • Which identity actually owns the inbox this form delivers to, and does that match who’s verifying it?
  • Is the form-backend token treated as a secret, or just pasted in plaintext in the page source?
  • What happens to a submission if the AJAX call fails silently — does the POST fallback actually fire?
  • Does the public deployment expose anything (tokens, internal paths, draft content) that the local-only version didn’t?
  • Is the business’s public trust story (sample report, case study) accurate, or aspirational?

🚨 Detection Opportunities

Potential monitoring ideas — applied to my own funnel instead of a client’s:

  • form submissions with no corresponding delivery confirmation on the receiving end
  • a production token that changes without every dependent page being updated
  • a live deploy that quietly reintroduces something a review would have blocked
  • account-identity mismatches between “who has access” and “who needs to verify delivery”

Example:

project=website-mini-audit-funnel
change_type=production_intake_deployment
risk_area=identity_access_mismatch
triage=confirm_recipient_account_owns_verification_access

🧭 MITRE ATT&CK Techniques

Not directly applicable — this is a legitimate business delivery pipeline, not adversary activity. No mappings claimed here.

🗺 Visual Investigation Diagram

mailto: link
    ↓
Structured intake funnel (AJAX + POST fallback)
    ↓
Production token wired in
    ↓
Live test submission
    ↓
Access-mismatch found (wrong inbox owner)
    ↓
GitHub Pages deploy prepared, gap documented before going further

⚠ Challenges

The temptation was to treat the deploy as “done” once the live test submission worked. It didn’t account for who could actually verify delivery on the receiving end — and that gap wouldn’t have shown up in a functional test, only in an access review.

📚 What I Learned

I learned that a working end-to-end test proves the pipe works, not that the right person is on the other end of it. Functional testing and access verification are two different checks, and passing one says nothing about the other.

➡ Next Steps

  • Confirm the business inbox account can independently verify form-backend delivery before calling this production-ready
  • Get one real client testimonial to replace internal-only proof
  • Push the repo, enable GitHub Pages via Actions, and point the domain’s CNAME at it
  • Keep the production token synchronized if the form-backend endpoint is ever rotated

🧠 Reflection

Building the sales funnel was the easy part. Noticing that I couldn’t actually verify my own delivery pipeline — because I didn’t hold the right identity — was the more useful outcome of the day.

🧩 Lessons Learned

What worked

Testing the funnel end to end with real submitted data before calling the intake flow ready.

What broke

Delivery verification, because the connected account and the recipient account weren’t the same identity.

Why it broke

A successful test submission only confirms the pipe works, not that the intended party can see what came out the other end.

Fix / takeaway

Separate “does it function” from “can the right identity verify it” — treat them as two distinct checks, always.

📈 Skill Progression Context

This supports my cybersecurity progression because catching an identity/access mismatch in my own delivery pipeline — instead of only in a client’s environment — is the same access-control thinking the mini-audit service is meant to sell in the first place.

😄 TL;DR

Shipped a real intake funnel, then found out I couldn’t verify my own delivery because I was logged into the wrong inbox.