h5i-dev/h5i

Part of #496. Most authorization bugs are one cell in a table: this role, on this endpoint, got an answer it should not have. Write that table once as data, generate one h5i test file per cell, and run it against an application with three roles and a couple of wrong cells. Estimated effort: three to four hours. What to build A matrix file (YAML or CSV): roles down one side, endpoints across the other, and in each cell the expected outcome, such as allow or deny. Plus how each role logs in. A small generator that turns the matrix into .h5i-tests/tests/*.yaml, one actor per role, with the verdict as step expect clauses (a deny cell expects a 401 or 403, an allow cell expects a 2xx). There is no oracle script, so the generated tests are data and nothing else. Include anonymous as a role. A table that only lists signed-in roles never asks what a logged-out request gets. covers on each attack step and an openapi.yaml for the demo app, so --openapi reports which operations the matrix exerci

Part of #496. Writing the first h5i test file by hand is the slow part: the login request, the headers the application insists on, the ids to extract. A browser already recorded all of it. Turn a HAR export into an h5i.test/v1 skeleton that a person then edits into an attack, and show it on a small demo application. Estimated effort: two to three hours. What to build A small CLI (any language) that reads a HAR file and writes one test YAML: an actor, one requests entry per chosen request, and a flow that replays them in order. Let the user pick which entries to keep. A HAR from one page load often holds hundreds of asset requests. Turn values that a later request reuses (a session token in a JSON body, an id in a Location header) into an extract on the earlier step and ${name} on the later one, instead of copying the literal value. Never write a secret into the output. Cookies, Authorization headers and password fields become ${env.NAME} placeholders, and the tool prints the variable

Part of #496. #639 shows one bug turning one check red. This one is a reference for writing tests: a small, deliberately vulnerable application with one h5i test file per bug class, and each file reaches its verdict a different way. Someone testing their own application should find the closest file here and copy it. Estimated effort: three to four hours. What to build Any stack, seeded fixture users, docker compose up -d --wait on one port. Every bug is behind a switch (an env var or a query flag is fine) so the same suite can be run against the vulnerable and the fixed build. At least these five files in .h5i-tests/tests/, each named after the verdict style it uses: oracle: a shell script over $H5I_TEST_RESULT compares two responses. A user can read their own order and gets refused on someone else's. expect: no oracle at all. A step expect on status, body or header catches an admin endpoint that answers a normal user with 200. variants: path or method variants of one request, where

Part of #496. action.yml covers GitHub Actions. Everywhere else the same run is install.sh --test, one h5i test command, and a junit.xml the CI system already knows how to render. Write those pipelines once so nobody has to guess them: GitLab CI, CircleCI and Jenkins. Estimated effort: an hour or two, plus the free tier accounts. What to build One pipeline file per system, each actually run against a throwaway application, with a link to its green build and its red build. Pin the h5i version in the install step. A security gate that silently follows the latest release is not a gate. Publish junit.xml to the system's native test report, and keep the output directory as a build artifact, on failure too. Keep the exit codes meaningful: 0 passed, 1 a test or the coverage gate failed, 2 the run could not decide. Do not collapse 2 into a pass with || true. Say in the README where the target URL comes from on each system, because a service container, a compose step and a deployed staging URL

Part of #496. h5i test writes result.json and junit.xml, and the action writes a two line step summary. Nobody reads a step summary. Turn a run into a sticky pull request comment that updates in place, so a reviewer sees which security property broke without opening the run. Estimated effort: an hour or two. What to build A composite action, or a small CLI that an action calls, reading result.json and writing one comment per pull request, edited on every push rather than appended. Per test: the id, its pass, fail or error status, and for a failure the oracle's exit code and the tail of its output. Print the coverage line only when coverage is present in the JSON, because it is absent without --openapi. error is not fail. Exit 2 means the test could not decide, and a comment that renders that as a security failure teaches people to ignore the comment. Never paste response bodies or request headers. The artifact directory is owner-only because the evidence may hold session cookies and o