Matheus Comin.
MATHEUS COMIN / APPLICATION SECURITY

Software developer moving into AppSec & Product Security

I care about the boundary, not just the happy path.

My background is in software development and APIs. I am applying that perspective to security engineering: tracing who can call an endpoint, which data they can reach, and what happens when the expected flow breaks.

These two projects are how I put that thinking into practice — with reproducible attacks, constrained fixes, and test evidence I can walk through.

Private engineering labs · Public-safe case studies · No production certification claimed

02Independent case studies
12 + 12Security milestones
53.NET lab regression tests
793Multi-tenant .NET tests
01 / A PERSONAL NOTE

I started with software. Security changed how I look at it.

Working with backend services and APIs taught me to think about requests, data flows and failure handling. In my AppSec transition, I have been focusing on the assumptions hidden between those pieces: the route that selects a tenant, the permission that authorizes a write, and the transaction that commits a change.

I did not want a portfolio built only from security buzzwords. I wanted to show specific design decisions, deliberately hostile test cases, and an honest answer to “what did this actually prove?”

BACKEND & APIsTHREAT MODELINGTESTABLE CONTROLS
SELECTED PROJECTS / 01—02

Two projects, built to answer different questions.

The first examines vulnerabilities and their remediations. The second tests how security controls behave together in a multi-tenant product. Both include mistakes, investigations, and explicit evidence limits.

01 / FIND & FIXVULNERABILITY LAB

.NET Application Security Lab

I examined how ordinary application features fail under malicious inputs — from an order ID that belongs to another user to an outbound request that should never reach an arbitrary host. Each finding has a reasoned fix and regression coverage.

ASP.NET CoreAngularOWASP ZAPSAST / SCASBOM
Read the case study
02 / DESIGN & VERIFYSAAS TRUST BOUNDARIES

Multi-Tenant SaaS Security Engineering

I explored what it takes to keep tenant boundaries trustworthy across API permissions, PostgreSQL RLS, sessions, webhooks, auditing and caching. A transaction timing bug found in the Master Review became the clearest lesson.

.NET 10PostgreSQL RLSTestcontainersPlaywright
Read the case study
EVIDENCE / READ WITH CONTEXT

What the tests actually showed.

Numbers are tied to observed GitHub CI revisions in private repositories. They describe covered scenarios, not a production certification or immunity from unknown vulnerabilities.

01 / APPSEC LAB

53 / 53 backend tests

Verified at the integrated .NET lab source revision. Review evidence also includes automated SAST, SCA, secret scanning, SBOM and ZAP DAST validation; DAST is documented from its separately reviewed revision.

02 / MULTI-TENANT SAAS

793 / 793 .NET tests

Successful exact-merge-SHA CI, including real PostgreSQL Testcontainers, plus 17 Chromium tests and 36 pipeline-policy test cases. The targeted attack suites are subsets of the 793.

03 / SECURITY REVIEW

One race, reproduced & fixed

An independently concurrent PostgreSQL reader could refill stale project cache data before a writer committed. The review added post-commit invalidation and verified commit/rollback paths.

MY WORKING METHOD

How I approach a security question.

The process starts with a specific failure hypothesis and ends with its boundaries. A successful test answers that hypothesis — not every possible security question.

01 — MODEL

Map the trust boundary

Identify actors, assets, attacker-controlled inputs and ownership of each security decision.

02 — CHALLENGE

Make it fail safely

Design adversarial cases for denied access, tampered data, unexpected state and concurrent operations.

03 — REMEDIATE

Place the control correctly

Fix the cause at the identity, API, browser, network, database or pipeline boundary.

04 — VERIFY

Record exact evidence

Use reproducible tests and revision-specific CI; record what remains outside the verified scope.

ASSURANCE / TRANSPARENCY

The limitations belong in the story.

These are independently built educational portfolio labs, not live customer systems. The original GitHub repositories are private. Source access, publication and deployment are separate decisions.

  • Passing tests validate named scenarios; they do not establish universal absence of vulnerabilities.
  • No production deployment, formal external penetration test, or compliance certification is claimed.
  • Persistent self-hosted runners and deployment governance have documented operational limitations.
  • Source code, raw runner logs, credentials and private evidence links are intentionally excluded from this public-safe view.