What the testing covers
Each engagement is a timeboxed review of one client-owned web application, covering what is in the written scope:
- Frontend and session: pages, forms, uploads, tokens, cookies, and what a signed-in user can reach that they should not.
- Authentication and identity: login, SSO, password reset, invite flows, role checks, and tenant boundaries.
- API and backend: the calls the application's own UI makes, plus missing authorization, object-level access control, upload paths, and export or download controls.
What it does not cover
- Systems the client does not own or control. No scanning of a neighboring tenant, a vendor, or any third party.
- Multi-week infrastructure red teaming or social engineering.
- Anything outside the written scope or the agreed test window.
Before any testing starts
- Written authorization from the owner of the system. I do not start without it.
- Written scope: the target URL (production or staging), the roles to test, out-of-scope rules, and a test window.
- Access from the owner: test credentials or an SSO invite issued by the client. Testing begins only once that access works.
- At checkout, the client enters the target URL and confirms they are authorized to approve the work.
During testing
- I work as a real user of the application, and as a second, more privileged role when the client grants one.
- I stay inside the agreed scope and rules, and keep notes by severity as I go.
- Any test state I create is put back the way I found it.
Reporting
- The client receives a written, severity-ranked report with practical remediations.
- Reports contain no exploit payloads and no credentials.
- One retest of the same application is included within 14 days, so the client can confirm the fixes work.
Confidentiality
Client names and applications are never published on this site. The one engagement shown in the portfolio is described only as a private SaaS analytics platform, with aggregate results (2 High, 1 Medium, 7 Low and 7 Informational findings) and no technical detail. A redacted sample report is available on request, with no client names and no exploit payloads.
Use of AI tools
I use AI assistants, including Claude, in this work: reviewing what I observe on in-scope targets, organizing findings, and writing reports and remediation guidance. The same rules apply to everything those tools touch: only systems covered by the client's written authorization, only inside the agreed scope, and no exploit payloads in what gets delivered.
Honest limits
This is a focused application security review, not a certified CREST, SOC 2 or PCI engagement. I do not hold security certifications and do not claim any.
Contact
Questions about this practice, or about a specific engagement, go to security@michaelheredia.com. Details of the paid offer are on the Security Review page.