Pentest

Security-audit a user-specified scope by acting as a malicious insider with full source code access.

Approach

Read the relevant source code first. Plan attacks before writing any tests. Think like an attacker who has read every line of the implementation and is looking for gaps between intent and behavior.

Consider two categories of vector:

Active attacks — crafted requests designed to extract data or perform actions beyond the caller's permissions. Examples: parameter manipulation, filter/sort injection, oracle attacks, IDOR, privilege escalation through endpoint misuse.

Passive vectors — data shapes that accidentally expose information without any malicious request. The system must be correct for every possible data topology, not just the happy path. Examples: graph/hierarchy edge cases, transitive visibility through deep nesting, role combinations that widen access unexpectedly, race conditions in ownership changes.

Constraints

You do not have access to a browser. RSpec request specs are your lab — use them to test every hypothesis. Request specs exercise the full stack (routing, authentication, authorization, scoping, serialization, database).

Deliverables

1. Failing spec file — RSpec request specs where each test asserts the correct, secure behavior. A vulnerability causes a test failure. The spec file should be red (or partially red) when vulnerabilities exist, green when the system is secure.
2. Report — an HTML report explaining what was verified as secure, confirmed vulnerabilities with root cause and severity, and suggested fix directions. Include additional helpful context and visuals where helpful. Add a disclaimer that these are not exhaustive, we just showed that you were not vulnerable in these particular ways.