🔄 Topic

Running the mini-audit against the Farina website I built myself, and remediating the findings.

🎯 Goal

Close the loop: not just find issues, but fix them in production and verify the fixes deployed.

🛠 What I Did

I pointed my own audit process at the Farina farm website and treated the report like it came from an external assessor. Then I fixed the findings: hardened the firewood order form against spam, added a security contact and well-known files (and fought GitHub Pages to actually publish hidden dotfiles in the artifact), fixed canonical URLs and sitemap indexing, improved SEO issues flagged in the report, and corrected inaccurate content like an outdated Google review count.

Main areas covered:

  • form anti-spam hardening
  • security.txt and well-known files
  • Pages artifact publishing quirks
  • canonical URLs and sitemap fixes
  • accessibility refinements on the order form
  • content accuracy as a trust issue

🔗 Key Cybersecurity Connections

Remediation is where audits earn their value. Public input forms are an abuse surface, a security contact is basic vulnerability-disclosure hygiene, and deployment pipelines can silently drop the exact files your security posture depends on.

🔍 Investigation Questions

  • Did every accepted finding get an actual fix?
  • Did the deployment pipeline publish the fix, or only the repo?
  • Can someone report a vulnerability to this site easily?
  • Is the order form abusable for spam or injection?
  • Do the pages the search engine indexes match the pages that exist?

🚨 Detection Opportunities

Potential monitoring ideas:

  • spam submission spikes on the order form
  • missing well-known files after a deploy
  • sitemap and canonical URL drift
  • unreviewed changes to public input handling
  • security header regressions

Example:

project=farina-farm-website
change_type=security_remediation_deploy
risk_area=public_input_and_disclosure_channels
triage=verify_fix_is_live_not_just_committed

🧭 MITRE ATT&CK Techniques

Possible mappings depending on confirmed behavior:

  • T1190 — Exploit Public-Facing Application
  • T1566 — Phishing
  • T1195 — Supply Chain Compromise

🗺 Visual Investigation Diagram

Own audit report
    ↓ Accepted findings
    ↓ Fixes in code
    ↓ Deployment verification
    ↓ Live posture improved

⚠ Challenges

The challenge was GitHub Pages not publishing hidden files by default, which quietly broke the well-known files. A fix that exists in the repository but not in production is not a fix.

📚 What I Learned

I learned that verification after deployment is a separate step from the fix itself. I also learned that auditing your own work stings a little, and that is exactly why it is worth doing.

➡ Next Steps

  • Re-run the audit checklist against the live site
  • Keep the security contact information current
  • Watch form submissions for abuse patterns
  • Fold the Pages artifact lesson into the audit checklist

🧠 Reflection

This was useful because being on both sides — assessor and remediator — showed me how findings feel to the person who has to fix them, which will make my future reports better.

🧩 Lessons Learned

What worked

Treating my own report as if a stranger wrote it.

What broke

Well-known files missing from the deployed artifact.

Why it broke

The deployment pipeline excluded hidden files by default.

Fix / takeaway

Always verify security fixes on the live system, not just in the repository.

📈 Skill Progression Context

This supports my cybersecurity progression because the full cycle — assess, prioritize, remediate, verify — is what real security work looks like, not just finding problems.

😄 TL;DR

Audited myself, fixed it, then checked the fix was actually live.