🔄 Topic

Reviewing the contact flow as both a conversion path and an abuse target.

🎯 Goal

Understand how form validation and abuse controls reduce noise and protect a small public website.

🛠 What I Did

I looked at the contact and order-related flow as a public input surface. Even a simple form can be abused by bots, spam campaigns, malformed input, or automated submissions. The Farina project uses structured validation thinking with React Hook Form and Zod, plus practical anti-spam ideas such as honeypot fields, timing checks, and cooldown protection. The point was not to pretend this is enterprise-grade security. The point was to reduce obvious abuse while keeping the form usable.

Main areas covered:

  • field validation
  • clear error messages
  • honeypot field
  • submission timing checks
  • cooldown protection
  • safe handling of user input

🔗 Key Cybersecurity Connections

Forms matter because user input is where many web problems start. Even static frontend projects need to think about abuse paths before adding backend services or integrations.

🔍 Investigation Questions

  • Which fields accept user input?
  • What input is required?
  • What happens with malformed input?
  • Can bots submit the form repeatedly?
  • Are errors helpful without leaking implementation details?

🚨 Detection Opportunities

Potential monitoring ideas:

  • submission spikes
  • many failed validation attempts
  • honeypot field populated
  • rapid repeated submissions
  • same IP or user agent abusing the form

Example:

project=farina-farm-website
change_type=public_website_update
risk_area=repository_deployment_or_public_input
triage=review_change_intent_and_validate_build

🧭 MITRE ATT&CK Techniques

Possible mappings depending on confirmed behavior:

  • T1190 — Exploit Public-Facing Application
  • T1110 — Brute Force
  • T1595 — Active Scanning

🗺 Visual Investigation Diagram

Public form
    ↓ Validation
    ↓ Anti-spam checks
    ↓ Submission handling
    ↓ Monitoring/maintenance

⚠ Challenges

The challenge was balancing protection and usability. Too much friction can hurt real customers; too little protection invites abuse.

📚 What I Learned

I learned that form security starts with simple controls: validate, limit, monitor, and avoid trusting input.

➡ Next Steps

  • Review form fields
  • Keep validation strict but user-friendly
  • Plan backend handling carefully if serverless forms are added

🧠 Reflection

This was useful because it turned a real project into security-aware learning without pretending that every task was a pure cybersecurity lab.

🧩 Lessons Learned

What worked

Thinking about abuse before backend integration.

What broke

Assuming a small form is harmless.

Why it broke

Any public input can become a target.

Fix / takeaway

Treat every form as an input boundary.

📈 Skill Progression Context

This supports SOC progression because many alerts and incidents start with public-facing inputs: forms, login pages, APIs, and upload points.

😄 TL;DR

A contact form is also an attack surface.