Method Notes
A short outline of how I approach web application review, evidence, and interpretation.
This page is not a service description. It is a compact statement of method: what matters, what evidence is useful, and what should remain in bounds during security review.
Core Questions
Most review work reduces to a few recurring questions about real behavior.
- What trust assumptions does the application make?
- Where can state, identity, or authorization be confused?
- What evidence shows a flaw is real rather than theoretical?
- How should a finding be framed so remediation is proportionate?
OWASP guidance is useful here, especially as a vocabulary for coverage, not as a substitute for interpretation.
Working Sequence
- Frame the surface: identify the application boundary, roles, and sensitive actions.
- Walk the trust model: follow authentication, session, and authorization paths.
- Validate behavior: reproduce issues with the minimum action needed to confirm them.
- Interpret impact: separate exploitability, exposure, and operational relevance.
- Write clearly: document what was observed, why it matters, and what should happen next.
Good review work is usually quiet, narrow, and evidence-led.
Boundaries
- Authorization matters before any technical method does.
- Review should stay inside explicit targets and intended depth.
- Evidence collection should be minimal and defensible.
- Claims should stay tied to observed application behavior.
Writing Bias
- Prefer confirmed behavior over tool output.
- Prefer narrow claims over dramatic language.
- Prefer remediation clarity over severity theater.
- Prefer context over checklist completion.
Contact
For a personal note or question about the writing here, email [email protected].
Related support pages: Boundaries and Disclosure.