Cagamas Whistleblowing Form

This project wasn’t about visuals — it was about trust.

The whistleblowing form needed to handle sensitive submissions in a way that is:

• secure
• resistant to abuse
• safe for users to interact with

Which meant treating every input as a potential risk.

I developed the frontend form with a defensive approach, ensuring that the system cannot be easily exploited through:

• file uploads
• malformed inputs
• intentional misuse

This wasn’t just validation — it was about closing gaps before they exist.

File Uploads Are Attack Surfaces
Allowing uploads introduces real risk.

So I enforced strict controls:

• blocked executable and unsafe file types
• constrained file sizes
• ensured only expected formats are accepted

No “trust the user” shortcuts.

Validation Is Not Just UI Feedback
Most forms validate for UX.

This one validates for security.

Every input is treated as untrusted:

• sanitized before submission
• structured to avoid injection risks
• aligned with backend expectations

Keeping It Simple (On Purpose)
Security-heavy forms often become intimidating.

I kept the interface minimal and direct, so users can focus on reporting — not figuring out how to use the form.

• Nuxt-based frontend
• Strict file validation logic
• Input sanitization strategies
• Defensive form handling patterns

Balancing Security vs Usability
Too strict → users get blocked
Too loose → system gets abused

→ I implemented constraints that protect the system without making the form frustrating to complete.

Preventing Misuse Without Overengineering
It’s easy to overcomplicate “secure systems”.

→ I focused on practical safeguards that actually reduce risk, instead of adding unnecessary complexity.

A form that doesn’t just “work” — it holds up under bad input, which is exactly what it’s supposed to do.