> For the complete documentation index, see [llms.txt](https://bugrecon.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://bugrecon.gitbook.io/docs/features-list/scopes-overview.md).

# Scopes

A **scope** is a reconnaissance target you create from a project: a list of domains (and later subdomains). You create a scope by entering or uploading domains; then, from the **scope detail** page, you run the **scan types** you need (subdomain, port, HTTP, vulnerability, etc.).

![Scopes](https://1075470145-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FV2n4UTcrS4SHhY2NTi0v%2Fuploads%2Fgit-blob-78793c666d222a6ba08a73e67c01dcbdad940bce%2Fscan.png?alt=media)

![Scopes](https://1075470145-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FV2n4UTcrS4SHhY2NTi0v%2Fuploads%2Fgit-blob-7989887e72425450323b069852954f183f7f8815%2Fscan2.png?alt=media)

## Scan types

Each type focuses on a different aspect of reconnaissance. Availability depends on your subscription plan.

| Scan type                                                                           | Brief description                                                               | Plan                         |
| ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | ---------------------------- |
| [Subdomain scan](/docs/features-list/scopes-overview/subdomain-scan.md)             | Passive/active/AI-powered subdomain enumeration                                 | Premium / Enterprise         |
| [Port scan](/docs/features-list/scopes-overview/port-scan.md)                       | Scan ports on subdomains (simple or version)                                    | All                          |
| [HTTP scan](/docs/features-list/scopes-overview/http-scan.md)                       | Probe HTTP/HTTPS with configurable ports and options                            | All                          |
| [URL scan](/docs/features-list/scopes-overview/url-scan.md)                         | Collect publicly available URLs from subdomains                                 | Basic / Premium / Enterprise |
| [Vulnerability scan](/docs/features-list/scopes-overview/vulnerability-scan.md)     | Run vulnerability scanning (e.g. Nuclei) on subdomains                          | Basic / Premium / Enterprise |
| [Leaks scan](/docs/features-list/scopes-overview/leaks-scan.md)                     | Search for sensitive data leaks                                                 | Basic / Premium / Enterprise |
| [Basic auth scan](/docs/features-list/scopes-overview/basic-auth-scan.md)           | Detect and optionally bypass basic authentication                               | All                          |
| [Domain takeover scan](/docs/features-list/scopes-overview/domain-takeover-scan.md) | Check for subdomain takeover opportunities                                      | All                          |
| [Screenshot scan](/docs/features-list/scopes-overview/screenshot-scan.md)           | Capture screenshots of web responses                                            | All                          |
| [JavaScript scan](/docs/features-list/scopes-overview/javascript-scan.md)           | Analyze JS files for secrets and API endpoints                                  | Basic / Premium / Enterprise |
| [AI scan](/docs/features-list/scopes-overview/ai-scan.md)                           | AI-powered triage: get a prioritized list of the best targets from your results | Basic / Premium / Enterprise |

## Subdomain search & filtering

The scope detail page includes a search bar that supports both free-text search and a structured **key:value** query syntax.

### Free-text search

Type any term to search across all fields: hostname, IP, port, technology, HTTP status code, page title, server, and URL. Regular expressions are also supported (e.g. `prod.*\.example`).

### Structured query syntax

Use `key:value` pairs separated by `and` to build precise filters. Prefix any condition with `not` to negate it.

```
hostname:*prod* and port:443
hostname:*staging* and not status:200
tech:*nginx* and not cms:WordPress and port:443
```

**Available keys**

| Key                            | Matches             |
| ------------------------------ | ------------------- |
| `hostname` / `domain` / `host` | Subdomain name      |
| `ip`                           | Resolved IP address |
| `port`                         | Open port number    |
| `tech` / `technology`          | Detected technology |
| `status` / `status_code`       | HTTP status code    |
| `title`                        | Page title          |
| `server`                       | Server header value |
| `url`                          | Full URL            |
| `cms`                          | Detected CMS        |

**Wildcards**

* `*` matches any number of characters: `hostname:*prod*`
* `?` matches exactly one character: `status:20?`
* Without wildcards, the value is matched as a substring: `tech:nginx`

**Port and status: subdomain-level vs port-level filtering**

A subdomain can have multiple open ports (e.g. 21, 443, 8090). This creates two distinct filtering needs:

| Syntax         | Meaning                                                  | Example        |
| -------------- | -------------------------------------------------------- | -------------- |
| `port:443`     | Subdomain **has** port 443 open                          | `port:443`     |
| `not port:443` | Subdomain has **no** port 443 at all                     | `not port:443` |
| `port:!443`    | Subdomain has **at least one open port that is not** 443 | `port:!443`    |

The same `!` prefix applies to `status`: `status:!200` matches subdomains with at least one HTTP response that is not 200.

Use case: `example.com` has ports 21, 443, and 8090 open.

* `port:443` → ✅ matches (has 443)
* `not port:443` → ❌ excluded (has 443)
* `port:!443` → ✅ matches (has 21 and 8090, which are not 443)
* `port:21 and port:!443` → ✅ matches (has port 21, and has ports other than 443)

**Logical operators**

* `and` - all conditions in a group must match
* `or` - at least one group must match (`or` has lower precedence than `and`)
* `not` - negates the following condition (subdomain-level)

```
tech:swagger or tech:graphql
hostname:*api* and port:443 or hostname:*admin* and port:443
ip:* and port:!443
```

**Standalone keywords**

Some filters don't require a value - type the keyword alone (followed by a space):

| Keyword        | Matches                                                           |
| -------------- | ----------------------------------------------------------------- |
| `wildcard`     | Subdomains whose hostname starts with `*.` (wildcard DNS entries) |
| `not wildcard` | Subdomains that are **not** wildcard entries                      |

> **Important:** always add a trailing space after `wildcard` (e.g. `wildcard` or `not wildcard` ) to avoid the parser treating it as an incomplete `key:value` expression. Without the space, intermediate typing can produce unexpected results.

These keywords can be combined with other filters:

```
wildcard and port:443
not wildcard and tech:*nginx*
```

**Color coding**

Active filters are displayed as chips below the search bar: **green** for positive conditions, **red** for negated (`not`) conditions, **yellow** `or` separator between groups.

### Examples

| Query                              | Effect                                                   |
| ---------------------------------- | -------------------------------------------------------- |
| `hostname:*prod*`                  | Subdomains containing "prod"                             |
| `port:443`                         | Subdomains with port 443 open                            |
| `not port:443`                     | Subdomains with no port 443                              |
| `port:!443`                        | Subdomains with at least one port other than 443         |
| `hostname:*prod* and not port:443` | Prod subdomains with no port 443                         |
| `status:200 and tech:*wordpress*`  | WordPress sites returning 200                            |
| `tech:swagger or tech:graphql`     | Subdomains exposing Swagger or GraphQL                   |
| `port:21 and port:!443`            | Subdomains with FTP open and at least one non-HTTPS port |
| `wildcard`                         | Wildcard DNS entries only (`*.example.com`)              |
| `not wildcard`                     | Non-wildcard subdomains only                             |
| `wildcard and port:443`            | Wildcard entries with HTTPS open                         |

## Where to run scans

* **Scope detail page:** Each scan type has a section with options, subdomain selection, and a Run button.
* **Tasks:** Schedule scan types automatically (interval, cron, or date).
* **Spraying:** Run HTTPX or Nuclei across multiple scopes at once.

## Quota

Starting a scan consumes your scan quota (Free: 15, Basic: 300, Premium/Enterprise: unlimited).

## Collaboration

Premium and Enterprise users can **share a scope** with other users via [Collaboration](/docs/features-list/collaboration.md). Invitees get read-only or writer access to the scope; they can view results and (if writer) run scan types without being the owner.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://bugrecon.gitbook.io/docs/features-list/scopes-overview.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.