What to Expect

This is exactly what happens when you engage us. Not a pitch. A walkthrough from a real assessment on a safety-critical dating platform - from first contact to final report.

Phase 1

We Find Something in Your Public Code

Before you pay anything, we look at what is already public. Your GitHub repos, open-source libraries, public APIs, deployed contracts. We find a real vulnerability and deliver a full report with a working Proof of Concept.

No charge. No obligation. The report is yours regardless of whether you engage us.

From the assessment The platform had 13 API controllers exposed via Express.js. We started with the public-facing endpoints - the authentication flow, the registration system, and the safety controller surface area. Within the first pass, we identified the JWT implementation, the rate limiting mechanism, and three safety-critical subsystems that handled real-world user protection.
Phase 2

You Tell Us What Matters Most

Every business has a priority. Payments. User data. Authentication. API security. You tell us what yours is, and we scope the entire assessment to that.

From the assessment The client identified user safety mechanisms as the priority. This platform had a Dead Man's Switch timer for physical meetups, a shadow audit system for post-meeting accountability, a vouch syndicate for trust verification, and a geofencing layer for location validation. These were the systems that protected real people in real situations. That became the scope.
Phase 3

You Provide a Copy of Your System

You give us a production-equivalent copy of your codebase - same code, same architecture, no real user data. We set it up on our own machines. Nothing touches your live systems. Ever.

From the assessment Received the full codebase: Express.js backend with TypeScript, SQLite database, authentication middleware, 13 controller modules, safety utility functions, and a geospatial anti-spoofing layer. Ran the entire system on localhost:5000. Database initialised with migrations. Seed data loaded. System fully operational locally within 20 minutes.
Phase 4

We Test Everything Against the Threat Checklist

Every endpoint, every flow, every edge case - tested manually against modern attack patterns. This is not an automated scan. It is a human reading your code, understanding your logic, and trying to break it the way a real attacker would.

The threat checklist covers:

  • Authentication and authorisation bypass
  • Business logic abuse - can safety mechanisms be circumvented?
  • Injection (SQL, command, template)
  • IDOR - can one user access another user's data?
  • Data exposure through error handling, logs, or API responses
  • Session management and token security
  • Rate limiting effectiveness
  • Input validation and content safety
From the assessment We tested whether the Overwatch safety timer could be deactivated without the correct PIN. Whether the shadow audit system could be manipulated to falsely flag a user. Whether the vouch syndicate could be gamed to bypass the two-strike ban mechanism. Whether the geofencing anti-spoofing layer could be bypassed via header injection. Whether JWT tokens could be forged or reused. Whether the immutable blacklist could be circumvented through re-registration.
Phase 5

You Get a Full Report

Every finding has four parts: what is vulnerable, why it is vulnerable, a working Proof of Concept that demonstrates the issue against your own code, and a recommended fix.

This is what a finding looks like in the report:

Overwatch Timer Deactivation Without Verification

High
Root Cause
The deactivateSwitch endpoint validates the PIN against the stored hash but does not verify that the requesting user is the same user who activated the switch. Any authenticated user with a valid JWT can attempt PIN deactivation on any active switch by iterating user IDs.
Impact
An attacker with a valid account can deactivate another user's safety timer during a physical meetup, preventing the emergency alert from firing. In a system designed to protect physical safety, this is a direct protection bypass.
Proof of Concept
Documented step-by-step reproduction against the localhost instance. Request, response, and database state before and after. Reproducible by the client on their own copy.
Recommended Fix
Add ownership verification: confirm userId === sw.user_id before allowing PIN validation. The switch should only be deactivatable by the user who activated it.

Rate Limiter State Not Persisted Across Restarts

Medium
Root Cause
The rate limiting implementation uses an in-memory Map that resets on every server restart. An attacker who triggers a restart (or waits for a deployment) gets a clean rate limit window.
Impact
Brute-force protection on authentication and registration endpoints is unreliable. In a production deployment with rolling restarts, rate limiting provides no sustained protection.
Proof of Concept
Restart the server process. Re-send the same requests. Rate limit counter resets to zero. Documented with request logs.
Recommended Fix
Move rate limit state to the database or a persistent store (Redis, SQLite table). Alternatively, use a middleware like express-rate-limit with a persistent store adapter.

The full report covers every finding at this level of detail. No scan output. No generic recommendations. Every finding is specific to your code, with a PoC that runs against your system.

Phase 6

Your Code Is Deleted

When the report is delivered, your codebase is permanently deleted from our systems. We retain a copy of the report for our records. You own the deliverables. The engagement is complete.

If you want follow-up testing after you have implemented the fixes, that is a separate engagement.

That Is the Entire Process

One price. One assessment. Every finding backed by a working Proof of Concept. No platform. No middleman.

Getting Started