When onboarding a web application into HackGATE, one of the most important steps is understanding exactly how the application is structured across domains and subdomains.
Many modern applications do not run entirely on a single hostname. Even if the user starts on one URL, the application may rely on separate domains for authentication, frontend delivery, backend APIs, static assets, or supporting services. If these are not identified correctly during setup, parts of the application may fail to load or bypass the intended proxied flow.
This article explains what to check before hackgating a web application and how to avoid the most common domain-related issues.
Before creating a HackGATE instance, review how the application is exposed publicly.
A common mistake is assuming that www.example.com and example.com are interchangeable. In practice, they may behave differently, redirect differently, or even serve different content. The same applies to applications split across multiple subdomains.
For example, an application may use:
www.example.comexample.comlogin.example.comapp.example.comapi.example.comstatic.example.comThese should not automatically be treated as a single entry point.
You should first determine:
www and non-www both existwww or Non-wwwAlways verify whether the application is designed to run on:
https://www.example.comhttps://example.comEven if one redirects to the other, this still matters during setup.
If the original application consistently uses www, then the HackGATE onboarding should reflect that. If it uses the apex domain without www, that should be configured instead. If both are actively used, both should be reviewed separately.
This is important because redirects, cookies, asset references, and authentication flows may behave differently depending on which hostname is used.
If the application uses multiple connected domains, each relevant one should typically have its own HackGATE instance.
For example, if the application is split across:
login.example.comapp.example.comapi.example.comthen each of these should be reviewed as a separate proxied component.
This ensures that the full application flow remains consistent when passed through HackGATE.
If only one domain is configured while the application depends on several others, users may experience broken redirects, failed authentication, missing assets, or API communication issues.
When a web application is accessed through HackGATE, the original application is served through the HackGATE proxy domain.
As part of this process, HackGATE rewrites links and replaces URLs in assets so that navigation continues through the proxied environment rather than pointing back to the original application domain.
This means that the application should be reviewed for:
If these references are not aligned properly, parts of the application may still try to load directly from the original domains instead of through HackGATE.
Authentication is often the most sensitive part of a HackGATE deployment.
Many web applications use a separate identity or login domain, such as:
login.example.comIf the application uses OAuth2 or OpenID Connect, the redirect URIs must be reviewed carefully when accessed through HackGATE.
Because the proxied application runs on a different effective domain, the corresponding HackGATE-based redirect URI must be explicitly whitelisted in the identity provider configuration.
If this is not done, login may fail with redirect mismatch or callback validation errors.
Typical symptoms include:
Applications often redirect across multiple domains during normal use.
You should verify:
example.com redirects to www.example.comIf these redirect paths are not accounted for, users may be sent out of the proxied flow or encounter loops and broken sessions.
Consider an application with the following structure:
https://www.example.com for the public landing pagehttps://login.example.com for authenticationhttps://app.example.com for the main user interfacehttps://api.example.com for backend communicationIn this case, you should not assume that a single HackGATE instance is enough for the entire platform.
Instead, review each relevant connected domain and create the necessary HackGATE instances accordingly. This allows HackGATE to proxy the complete application flow correctly and rewrite links and asset references across the full environment.
You may need to revisit the domain setup if you notice any of the following:
When hackgating a web application, the most important first step is understanding the full domain structure of the application.
Do not assume that a single URL represents the whole platform. Check whether the application uses www or non-www, identify all connected subdomains, and create separate HackGATE instances for each relevant domain such as login, app, and API endpoints.
This allows HackGATE to proxy the application correctly, rewrite links and asset references consistently, and preserve the expected user flow across the entire environment.
If you need support with onboarding a web application into HackGATE, please provide:
This helps the HackGATE team validate the expected routing and identify missing domain coverage faster.
