Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.hackgate.io/llms.txt

Use this file to discover all available pages before exploring further.

Before diving into HackGATE’s features, it helps to understand the key concepts and how they relate to each other.
The terms “HackGATE” and “site” are used interchangeably in the API (the resource is called /api/sites).
Your team’s account. All HackGATEs, projects, and members belong to an organization. You must have an organization before you can create a HackGATE.
A proxy instance that sits in front of one of your web applications. Creating a HackGATE provisions a unique *.hackgate.net subdomain (e.g. app-yourorg.hackgate.net). Researchers access your app through this URL instead of directly.Each HackGATE has:
  • Origin URL — your real application’s URL, never shared with researchers
  • HackGATEd URL — the *.hackgate.net proxy URL shared with researchers
  • Active/inactive status — you can enable and disable the proxy at any time
  • Start/stop schedule — optional scheduled windows that automatically enable and disable testing
A security professional testing your application through HackGATE. You can allow all authenticated researchers to access a HackGATE, or maintain a custom allowlist restricted to specific email addresses.
Controls who can access a HackGATE:
  • Open (hasCustomList: false) — any authenticated researcher can access your HackGATE
  • Custom list (hasCustomList: true) — only researchers on your allowlist can access your HackGATE
Controls how many requests per second a researcher can make to your HackGATE. You apply a rate limiter policy by name (e.g. "fixed", "sliding") to a HackGATE to cap throughput.
Path-level rules that return a specified HTTP status code for matching requests, preventing researchers from testing out-of-scope endpoints. Each rule has:
  • PathPrefix — the URL path prefix to match
  • HTTP methods — the request methods the rule applies to
  • Status code — the HTTP status returned for matched requests (e.g. 403)
  • Enabled flag — toggle the rule on or off without deleting it
A logical container for a testing engagement (e.g. “Q4 Web App Pentest”). Projects help you organize multiple HackGATEs and scope items under a single initiative. Each project has a name, description, type, launch and end dates, owner, vendor, and retest settings.
A specific target within a project — for example, an individual microservice, domain, or IP range. Each scope item has a name, type (e.g. web, api), location, and access type. Scope items define the boundaries of what researchers are authorized to test.
An automated security check that queries recorded traffic data to detect whether specific attack patterns were attempted against your application. Examples include path traversal, .git exposure, and SQL injection attempts.
Upload your API’s OpenAPI specification to enable API coverage tracking. This shows you which endpoints have been tested by researchers and which remain untouched.
Optional fields on a HackGATE where you can store test credentials and testing instructions for researchers. Use these to provide researchers with the information they need without sharing it outside the platform.
Your organization’s usage balance. Credits are consumed as you use HackGATE features. You can view your remaining credits in the organization settings.
Last modified on May 9, 2026