<!-- The first four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. --> ### Problem to solve <!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." --> As a site owner, I want to be able to validate that I own my site and am authorized to perform active DAST scans against my site, so that I can I can both fully test my site with an active scan and prevent anyone else from using GitLab DAST to attack my site. ### Intended users <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ * [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager) * [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager) * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Presley (Product Designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) * [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager) * [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#alex-security-operations-engineer) * [Simone (Software Engineer in Test)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#simone-software-engineer-in-test) * [Allison (Application Ops)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#allison-application-ops) * [Priyanka (Platform Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#priyanka-platform-engineer) * [Dana (Data Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#dana-data-analyst) --> * [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager) * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) * [Allison (Application Ops)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#allison-application-ops) ### User experience goal <!-- What is the single user experience workflow this problem addresses? For example, "The user should be able to use the UI/API/.gitlab-ci.yml with GitLab to <perform a specific task>" https://about.gitlab.com/handbook/engineering/ux/ux-research-training/user-story-mapping/ --> The user should be able to validate that they own their site via one of three ways: through a .txt file added to the root of their site, through an HTTP header added to their server, or via a meta tag on a page within their site. ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> 1. If the site is not already validated, this process should be initiated via a `Validate URL` button on a given profile within the profile library * If the site is already validated, the button should be replaced by text to indicate that the site is validated 1. Once the process is initiated, the user should be presented with a modal with three options: * Text file validation * Meta tag validation * HTTP Header validation 1. If the text file validation is selected, they should be presented with an option to download a .txt file that is named using a unique id that was generated for that individual site in that individual project. The content of the txt file should also only be that unique id. The user should be instructed to provide the path to the text file, using the target URL as the hostname. 1. If meta tag validation is selected, they should be presented with the code for a meta tag that contains the same unique id that they would be given in the .txt file. The meta tag should look like: `<meta name="gitlab-dast-validation" content="[unique-dast-id]">`. The user should be instructed to provide the path to the page with the meta tag, using the target URL as the hostname. 1. If HTTP header validation is selected, they should be presented with the header name and value to be added to their server. The header should look like 'gitlab-dast-validation:[unique-dast-id]`. The user should be instructed to provide the path a page that will serve up that header, using the target URL as the hostname. 1. Once any of those processes are finished, `Validated` will appear on each site profile with a validated URL within the profile library. - Note: Validation will not appear anywhere on the actual site profile page, _only_ within the profile library ### Design Site validation will exist outside of site profile creation. * [Site Validation design issue](https://gitlab.com/gitlab-org/gitlab/-/issues/255338) * Creation site profile flow: * [Figma file](https://www.figma.com/file/7CaJqOTOpPEOzkYkoU5bs5/DAST-Ondemand-Profile?node-id=5022%3A3301) ### Further details <!-- Include use cases, benefits, goals, or any other details that will help us understand the problem better. --> More discovery will need to happen around how this validation can be done automatically with review apps, so that the user doesn't need to do any work with it. ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)?--> Anyone with permission to create a site profile should be allowed to validate that site. ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/workflow.html#for-a-product-change * Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements * If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html --> * The documentation in https://docs.gitlab.com/ee/user/application_security/dast/#domain-validation will need to be updated to reflect this new process of domain validation. * A deprecation notice should go out that we are removing the old, insecure way of validating domains and site ownership. <!-- ### Availability & Testing This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning --> <!-- ### What does success look like, and how can we measure that? Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> <!-- ### What is the type of buyer? What is the buyer persona for this feature? See https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/buyer-persona/ In which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> ### Is this a cross-stage feature? <!-- Communicate if this change will affect multiple Stage Groups or product areas. We recommend always start with the assumption that a feature request will have an impact into another Group. Loop in the most relevant PM and Product Designer from that Group to provide strategic support to help align the Group's broader plan and vision, as well as to avoid UX and technical debt. https://about.gitlab.com/handbook/product/#cross-stage-features --> No, this is not a cross-stage feature. ### Tasks: * Front-end: * [x] Create basic front-end form * [x] Add option for text file validation * [x] Add option for meta tag validation * [x] Add option for HTTP header validation * [x] Add validation polling when "Validate" button is clicked * [x] Add visual indicator that site is validated * Back-end * [x] Create unique validation code when site profile is saved * [x] Add validation mechanism to search for unique code on the target site * [x] Store site validation confirmation in database ### Questions: 1. Should we retry a validation or require the user to click `validate` again? * We should probably retry 3 times to account for any network issues. Each try should have a 5 second timeout for the HTTP response. After the timeout or a failed response, we should have a 25 second sleep before the next retry. After 3 retries, we can show validation has failed and the user has to click the `validate` button again. 1. How should we poll? 1. Can you save a profile without the validation succeeding? * Yes, it will just show as a not validated site, which means that you can only use a passive scan profile with the site profile.