rorixrorix
sign in →

Pentesting

Rorix Pentesting is a peer product beside Rorix Supply Chain. It runs a reviewed, checksummed HTTP-hardening baseline and optional bounded OpenAPI operation tests against public web targets you control. Verify the domain with DNS before launching a run.

The current safe profile is an automated baseline, not a replacement for a human penetration test. It excludes destructive tests, denial-of-service payloads, credential attacks, and private-network targets.

How It Works

  1. You verify the target domain with a DNS TXT challenge
  2. You provide a public HTTP(S) target and optionally an in-scope OpenAPI specUrl or inline spec
  3. Rorix rechecks the DNS challenge and destination immediately before dispatch
  4. Independent engine jobs run through a durable queue with bounded retries and cancellation
  5. Results are reconciled into target-level finding lifecycles: new, recurring, fixed, and regressed

Standalone Pentests

Go to /dashboard/pentest, verify the domain you own, and run a one-off scan against that host or one of its subdomains. This is useful for staging environments, public APIs, and production surfaces you explicitly control.

Project-Scoped Pentests

When a project has a configured target URL, you can run pentests directly from the project view. The same target, run, and finding records power both the project view and the standalone Pentesting product.

Scanners

Curated HTTP Header Baseline

A template-based scanner using Rorix's currently bundled safe baseline:

  • Missing Content-Security-Policy
  • Missing Strict-Transport-Security
  • Missing X-Content-Type-Options

Rorix pins the bundled templates with the scanner image. A strict local runner accepts only GET requests to the verified base URL and literal missing-header matchers, so a report can be tied to the exact checks that ran.

OpenAPI Safe Testing

Accepts either an in-scope OpenAPI document URL or an inline document. The safe engine validates the document, inventories operations, and exercises at most 50 GET/HEAD operations with at most 100 requests. It performs a baseline request and no more than one bounded query-boundary case per operation. Write methods, credentials, destructive payloads, and external references are excluded.

The report records operations tested and skipped, total requests, and skip reasons. Public documentation and absent security schemes are informational signals; server errors or exposed stack details are findings, not proof of exploitability.

Execution Safeguards

  • Only HTTP(S) destinations inside the verified domain scope are accepted
  • Private, loopback, link-local, multicast, documentation, and other reserved network ranges are blocked
  • Redirect destinations are revalidated
  • Production scans default to ports 80 and 443
  • Requests, concurrency, response size, redirects, and total run duration are bounded
  • Runtime template updates do not exist; each baseline run records the pinned catalog version
  • Evidence is redacted, capped, and removed after the configured retention period

Results

Findings are grouped by severity: Critical, High, Medium, Low, and Info. Each report includes:

  • An executive summary with overall risk and totals by severity
  • Coverage details showing which engines ran and what completed
  • Findings with observed evidence, target, and detector-provided remediation guidance

Where the detector supplies it, a finding includes:

  • The target URL and matched path
  • A description of the vulnerability
  • Remediation advice

Export

Export your pentest results as CSV or JSON from the results page.

Limits

Usage is enforced at the organization level. When the current subscription limit is reached, the create-run API returns 403 with the current usage and limit.

Scheduling

Create daily or weekly schedules from a target page. Schedules use an explicit timezone, remember the authorizing user and safe profile, skip overlapping or unverified targets, and record skipped executions instead of hiding them.

CI Usage

CI can start only an existing, enabled, verified target. Create an API key with pentest.run and pentest.read, start in advisory mode, and enable enforcement only after reviewing the baseline. Policy evaluates new and regressed findings; accepted-risk and false-positive findings do not block.

- uses: rorix-io/rorix-pentest@v1
  with:
    api-key: ${{ secrets.RORIX_API_KEY }}
    target-id: 79c90894-5685-4bc8-8a2c-1a5379282d42
    threshold: high
    enforce: "false"

API Usage

Dashboard sessions use the product endpoints. Runs refer to a stored target instead of accepting an arbitrary URL:

curl -X POST https://rorix.io/api/pentest \
  -H "Cookie: your_authenticated_session" \
  -H "Content-Type: application/json" \
  -d '{
    "targetId": "79c90894-5685-4bc8-8a2c-1a5379282d42",
    "authorizationConfirmed": true,
    "idempotencyKey": "manual-2026-08-25-1"
  }'

Poll the job status:

curl https://rorix.io/api/pentest/job_xyz789 \
  -H "Cookie: your_authenticated_session"

For automation and SARIF, use the API-key-specific CI endpoints in the Pentest API reference.

PolicyCode Analysis Beta