# Security Testing > Security Testing - Skill: `handsomeboy990/security-testing` (Agent Skill, multi-file: 5 files) - Install (CLI): `npx skillmds@latest add handsomeboy990/security-testing` - Raw SKILL.md: https://api.skillmd.com/api/skills/handsomeboy990/security-testing/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: Handsomeboy990 (https://skillmd.com/u/handsomeboy990) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/handsomeboy990/security-testing --- # Security Testing `security-audit` reads the implementation. This skill exercises the running system to find out which of those controls actually hold, using accounts and targets the engagement owns. It is verification work, not adversarial work against anyone else's system. Everything here happens inside a boundary someone wrote down and approved. ## 1. Authorization comes first No request is sent until `resources/engagement-boundary.md` is filled in and confirmed. It records: ``` targets exact hosts, applications and paths in scope excluded everything else, named where confusion is likely environment which one, and whether it is production accounts the accounts the engagement owns, and their roles data which records may be created, read, modified destructive permitted or forbidden, in writing availability whether anything that could degrade service is allowed authorised by who, when, and in what form stop conditions what makes the tester stop immediately and report ``` Rules that never bend: - Only systems the engagement owns or is authorised to test are touched. - Third party services, shared infrastructure and other customers are out of scope even when they are reachable from the target. - Real user accounts and real personal data are never used as test material. - Nothing that degrades availability runs without explicit written permission, and never against production. - If a finding exposes real user data, testing stops there, the finding is reported immediately, and no further data is retrieved. ## 2. The order that finds the most ``` 1 authorization: roles, object level access, tenancy 2 authentication and session lifecycle 3 input handling, verified as rejection rather than exploitation 4 information disclosure through errors, responses and headers 5 uploads and file handling 6 transport, headers, cookies and CORS 7 rate limiting and abuse resistance 8 business logic boundaries ``` Authorization is first because it is where real products fail, and where the consequence is direct: someone reads someone else's data. ## 3. The role matrix Build it once, from the roles the product defines, then test every cell. Full template in `resources/role-matrix.md`. ``` rows every protected resource and action columns anonymous, each role, and an account from another tenant cells expected: permitted or denied result observed, per cell ``` Every denied cell is verified twice: once through the interface, and once by sending the request directly. A hidden button is not an authorization control, and the second check is the only one that proves anything. ## 4. Object level access For each resource reachable by identifier: ``` as an owner, note the identifier of a record you own as a second account the engagement owns, request that identifier repeat for read, update, delete, and any state transition repeat through every route that reaches the same object: detail, list filter, export, print view, attachment, webhook callback, admin path check sequential identifiers, and identifiers found in responses meant for another audience ``` The single most common real defect is one route that checks ownership and a second route to the same object that does not. ## 5. Tenant isolation For multi-tenant products, with two tenants the engagement owns: ``` read tenant A cannot read any object of tenant B, through any route write tenant A cannot create, modify or delete inside tenant B infer counts, totals, search results, autocomplete, error differences and timing must not reveal that an object of tenant B exists identify changing a tenant identifier in a path, a body, a header, a token claim or a query parameter does not move the caller invite invitations, shared links and exports do not cross the boundary admin an administrator of tenant A is not an administrator of anything else ``` Isolation is checked on every read path, not on the main one. Reports, exports, search indexes and background jobs are where it usually leaks. ## 6. Authentication and sessions ``` credentials the same response for an unknown account and a wrong password lockout repeated failures are throttled, and the throttle is per account and per source session a token or cookie is invalidated on logout, on password change, and on role change expiry an expired session is rejected everywhere, including background refresh calls fixation the session identifier changes on privilege change cookies HttpOnly, Secure, SameSite as the application requires recovery a reset link is single use, time limited, and does not confirm whether an address exists second factor cannot be skipped by going directly to the post login route ``` ## 7. Input handling The purpose is to confirm that invalid input is rejected safely, not to achieve an effect. Probes are minimal and non destructive: a value the application should refuse, sent once, with the response examined. ``` what is checked the rejection status is correct and consistent the error names the field, not the storage layer no input is reflected into a page or a header unescaped no input reaches a query, a command, a path or a template unbound size limits are enforced before parsing encoding differences do not bypass a validator ``` Where a probe suggests a real weakness, it is confirmed once, with the smallest possible evidence, and reported. Payload escalation, data extraction and persistence of anything harmful are out of scope. `input-validation` holds the constructive counterpart: what the code must do instead. ## 8. Disclosure and configuration ``` error responses: no stack trace, no SQL, no file path, no internal host debug endpoints, source maps, directory listings, backup files, version banners headers the application declares it sets, verified as actually present CORS: which origins are allowed, whether credentials are allowed with them caching of authenticated responses in shared caches identifiers that leak sequence, volume or ownership metadata in generated documents and images ``` ## 9. Uploads and business logic ``` uploads type verified by content, size limited, stored outside the web root or behind an authorising handler, filenames neutralised, downloads served with a safe content type and disposition logic price, quantity, role, status and owner never taken from the client state transitions that skip a required step are refused quotas and limits hold under repetition and concurrency refunds, credits and discounts cannot be applied twice webhooks verify their signature and refuse replays ``` ## 10. Findings Each finding carries the full record from `test-reporting`, plus: ``` confidence Confirmed, Potential, or Informational severity Critical, High, Medium, Low, Info category authorization, authentication, disclosure, validation, configuration, business logic impact what an attacker with this access could do, stated plainly evidence the minimum that proves it, with secrets and personal data removed fix the control that should exist, not a general principle ``` Confidence is never inflated. `Potential` means the control looked wrong and the confirmation was not run because the boundary forbade it, and that is a respectable result. Severity reflects consequence, not effort. ## 11. Prohibitions - Never touch a target outside the written boundary, even when it responds. - Never run availability affecting tests without explicit permission. - Never use, retrieve or store real user data as evidence. - Never keep a foothold, a persistent artefact or a modified permission after the test. - Never chain a finding further than proving it exists. - Never report a theoretical weakness as confirmed. - Never leave a credential, token or session in a report, a screenshot or a test file. - Never disclose a finding outside the agreed channel. ## 12. Protocol 1. Fill in and confirm the engagement boundary. Stop if it is not confirmed. 2. Take the surface inventory from `project-exploration` and `api-testing`. 3. Read the static findings from `security-audit` and target their claims. 4. Build the role matrix and test every cell, interface and direct request. 5. Run object level access and tenancy checks on every route to each object. 6. Test authentication and session lifecycle. 7. Run the safe input probes and the disclosure checks. 8. Check uploads, headers, cookies, CORS and rate limiting. 9. Test the business logic boundaries the product's money and state depend on. 10. Record each finding with its confidence and its minimal evidence. 11. Clean up: remove created records, revoke created sessions, leave nothing. 12. Report through the agreed channel, and hand fixes to the owning skill. ## 13. Auto-critique Score from 0 to 5: boundary respected and recorded, role matrix completed including direct requests, object level and tenancy coverage across every route, session lifecycle tested, evidence minimal and clean of secrets, severity and confidence honest, environment left in its original state. Threshold: no axis below 3, average at least 4. A campaign that tested authorization only through the interface scores 0 on that axis and is rerun. ## 14. Interfaces - Upstream: `quality-engineering` for the contract and the boundary, `security-audit` for the static findings, `api-testing` for the inventory. - Lateral: `input-validation` for the constructive rules, `bug-hunting` for the non security abuse of the same surfaces, `devops-core` for anything that belongs to the environment rather than the code. - Downstream: `backend-engineering` and `frontend-engineering` for fixes, `testing-quality` for the permanent authorization tests, `test-reporting` for the findings, `secrets-management` when a credential is exposed.