### Problem Projects and groups in GitLab can have `pages` attached to them. These `pages` can be either public or private. When deploying a `page` the site will be accessible under this structure ``` Group pages: https://groupname.gitlab.io Project pages owned by a group: https://groupname.example.io/projectname Project pages owned by a subgroup: https://groupname.example.io/subgroup/projectname ``` When visiting a private/restricted `page` the user will be redirected to an OAuth flow that authenticates the user. The flow will end up setting an access token in the form of a cookie. This cookie will be scoped to the URL `https://groupname.gitlab.io`. This cookie enables the user to access all `pages` that belong to projects or groups inside the top group. The cookie itself does not give access to `pages` belonging to projects where the user does not have access. It will only allow for authorization requests to be made. The scope of the cookie is important. As it is far from typical that a user have access to all projects and subgroups inside an organization. But as all `pages` are hosted under the same domain, public and private ones, a `page` belonging to one of the projects are allowed to send HTTP requests to other `pages` and read the response as `pages` in a group only differ in the `path` and not in the `origin`. CORS is thus not a problem. A user with access to only a single project in a group can create a `page` containing a script that will "reach out" to other `pages` to leak the data from them. When a user with access to these other projects visits the malicious `page` the victims' cookie will allow the request to be made, and the data will be accessible for the JavaScript. For more information: https://gitlab.com/gitlab-org/gitlab/-/issues/363329+ ### Proposed Solution All this should be behind a feature flag. 1. Add an option to users to use a unique pages domain, like: \  1. The unique domain must be unique 1. The unique domain creating can be a concatenation of the project's full path and a hash, like: `namespace/subgroup/.../project` => `namespace-subgroup-...-project-1a2b3c4d5e` 1. The unique domain must be send in the lookup path internal api `/api/v4/internal/pages` 1. Gitlab Pages must auto-redirect from the `default domain` (domain based on the top level namespace) to the `unique domain` 1. After the validation of the feature the unique domain must be the default behavior #### Next steps - [ ] Create a PoC to assess any big unknowns