Allowlist — Stinger Docs

How target URL approval works — submitting requests, pattern types, and the approval process

Every target URL must be approved in your Allowlist before Stinger can run attacks against it. This applies to both Web Console API targets and Adapter browser targets.

The Allowlist exists to ensure all engagements are authorized — Stinger is a security tool, and every attack needs documented approval.

How to submit a request

Go to Settings → Allowlist → Request new target.

Fill in the form:

Field	Description
Target pattern	The URL, domain, or IP you want to test (see pattern types below)
Pattern type	How to interpret the pattern — `domain`, `glob`, `ip`, or `cidr`
Purpose	Brief description of the engagement — what system you're testing and why

Click Submit request. Your request enters Pending status.

Pattern types

Choose the pattern type that matches what you want to cover.

Domain

Matches the exact domain and all its subpaths.

Pattern:  api.yourcompany.com
Matches:  api.yourcompany.com/chat
          api.yourcompany.com/v1/completions
Does not match: other.yourcompany.com

Use this for single-service targets.

Glob

Shell-style wildcard matching. * matches within a single segment; ** matches across segments.

Pattern:  *.yourcompany.com
Matches:  api.yourcompany.com
          chat.yourcompany.com
          dev.api.yourcompany.com  (only with **)

Use this when you need to cover multiple subdomains (e.g. dev, staging, and prod environments).

IP Address

Exact match on an IPv4 address. Use for targets without a domain name.

Pattern:  192.168.10.50
Matches:  http://192.168.10.50/
          http://192.168.10.50/api/chat

CIDR

Matches any IP in the subnet range. Use for internal network ranges.

Pattern:  10.1.210.0/24
Matches:  10.1.210.1 through 10.1.210.254

When to use CIDR

Use CIDR for internal lab environments or when you're testing multiple services across a known IP range. Combine with the Adapter for targets only reachable on internal networks.

Approval process

After you submit a request, AIM reviews it and sets the status to Approved or Rejected.

Status	Meaning
Pending	Awaiting review — no attacks can be launched yet
Approved	You can run attacks against this target
Rejected	Request denied — see the rejection note for details

Typical approval time: 1 business day.

High-risk targets: If the target pattern covers a high-risk system (e.g. financial transaction APIs, medical systems, critical infrastructure), AIM may reach out to schedule a review meeting before approving.

Attacks are blocked without approval

If a target URL is not on your approved Allowlist, both the Web Console and the Adapter will reject any attack attempt before sending a single prompt. Submit the Allowlist request first — you can set up your project and goals while you wait.

Rejection reasons

Common reasons a request is rejected:

Consumer service — The target is a public consumer platform (social media, public forums) outside the scope of security testing engagements
No authorization context — The purpose field doesn't describe a legitimate security testing engagement
Duplicate — An approved entry already covers this target
Out-of-scope pattern — The glob or CIDR is too broad (e.g. *.com)

If your request was rejected and you believe it should be approved, contact AIM via Help → Slack Connect or the contact form with more context about your engagement.

Managing approved entries

From Settings → Allowlist, you can see all your approved, pending, and rejected entries.

Approved entries:

Each entry shows the pattern, type, approval date, and which team member submitted it
Approved entries do not expire automatically — contact AIM if you want to deactivate one
You cannot self-approve entries — all approvals go through AIM review

Editing a pattern: You cannot edit an approved entry. If you need to change the scope, submit a new request and note that it replaces a previous entry.

How the Adapter enforces the Allowlist

The Adapter syncs your approved Allowlist from the Stinger backend every 60 seconds while running.

When you start an attack:

The Adapter checks the target URL against your approved entries
If no match is found, the attack is rejected immediately — no prompts are sent
If the Allowlist was updated (new approval came through), the Adapter picks it up within 60 seconds — no restart required

If you just got an approval and the Adapter still rejects the target, wait up to 60 seconds and try again — the sync may not have run yet.