Security checks and invalid input

swastik.codes/app

Many API security problems are not clever attacks. They are settings nobody checked: an endpoint that answers without a token, CORS that trusts any website, an error page that prints a stack trace. Swastik Codes checks your own requests for these, and sends invalid input to find the requests that make the server fail.

Run these checks only against APIs you own or are allowed to test, and use a test environment where you can.

Run the security checks

1. Open the collection runner and pick the requests (a folder, or all of them).
2. Switch to the Security checks tab.
3. Choose the environment and click Check.

Each request is sent as saved, and the response is read for:

• Plain HTTP to a public host (high when the request carries credentials).
• CORS that trusts any website. The request is sent with the Origin of a made-up site. If the response allows that origin, the server allows every origin; with Access-Control-Allow-Credentials: true any website could read a signed-in user's data.
• Missing security headers: Strict-Transport-Security on HTTPS, X-Content-Type-Options: nosniff, Content-Type.
• Cookies set without Secure, HttpOnly or SameSite.
• Version banners such as Server: Apache/2.4.41 or X-Powered-By: PHP/8.1.
• Error details: stack traces, panics and database errors in the body.
• Sensitive fields such as password_hash, client_secret or cvv in JSON responses.
• Signed-in responses that may be cached (no Cache-Control: no-store or private).

Then every request that sent credentials and succeeded is sent once more without them: auth set to No auth, the Authorization, API key and Cookie headers and key-like query parameters removed. If it still gets a 2xx, the endpoint does not enforce authentication. If a pre-request script puts the credentials back, the request is listed as not checked instead.

Findings are sorted by severity and labelled with the OWASP API Security Top 10 entry they belong to. No attack payloads are sent. Download the list with Report.

Test with invalid input

1. In the runner, switch to the Fuzz inputs tab.
2. Choose the environment and how many variants per request to send (30 by default).
3. Click Send.

Each request is sent once as saved, then in variants where one input is wrong:

{{variables}} in the body are kept, so the variants use the same environment as your normal run. DELETE requests are left out unless you tick Include DELETE requests, because their variants could remove data.

A well-behaved API answers invalid input with a 4xx and a clear message. The results flag:

• High: a 5xx. The server did not handle the input, and an unhandled error path is often where real bugs and leaks hide.
• Medium: no response at all (timeout or dropped connection).
• Low: input of the wrong type, or broken JSON, was accepted with a 2xx: it is not validated.
• Info: a missing field or a 10,000-character value was accepted. Fine for optional fields; otherwise add a length limit or make the field required.

Acceptance is only judged when the request worked as saved. If the baseline failed (for example 401), fix the environment first.

In CI

The swc CLI runs the same checks and fails the build when something reaches the level you choose:

swc security <collection> -e staging.json --fail-on high
swc security <collection> -e staging.json --fuzz --max-variants 20 --fail-on high --format json

--no-auth-check skips the unauthenticated pass, and --folder limits the run like swc run. See the CLI.

What you learned

• Security checks read every response for risky CORS, headers, cookies, banners, error details and sensitive fields, and resend signed-in requests without credentials.
• Fuzz inputs sends wrong, empty, long and boundary values and flags server errors and accepted invalid input.
• swc security makes both a CI gate.

Next: automate all of this in your CI pipeline.