Documentation: Update webhooks.md: clarify the risk / attack scenario concerning web hooks
What does this MR do?
Clarify the risk / attack scenario concerning web hooks, I found it somewhat unclear.
I have not explicitly mentioned it (it was already implied in the previous iteration), but I suppose the default setting to allow system hooks access to the local network presumably would does not prevent an over-eager GitLab admin to create a web hook with his/her API key to the GitLab server itself, thereby providing GitLab Admin access to anyone who triggers the webhook, even though the endpoint itself is fixed.
Related issues
Author's checklist
-
Follow the Documentation Guidelines and Style Guide. -
If applicable, update the permissions table. - [-] Link docs to and from the higher-level index page, plus other related docs where helpful.
-
Apply the documentation label.
Review checklist
All reviewers can help ensure accuracy, clarity, completeness, and adherence to the Documentation Guidelines and Style Guide.
1. Primary Reviewer
-
Review by a code reviewer or other selected colleague to confirm accuracy, clarity, and completeness. This can be skipped for minor fixes without substantive content changes.
2. Technical Writer
-
Optional: Technical writer review. If not requested for this MR, must be scheduled post-merge. To request for this MR, assign the writer listed for the applicable DevOps stage.
3. Maintainer
-
Review by assigned maintainer, who can always request/require the above reviews. Maintainer's review can occur before or after a technical writer review. -
Ensure a release milestone is set and that you merge the equivalent EE MR before the CE MR if both exist. -
If there has not been a technical writer review, create an issue for one using the Doc Review template.
Edited by 🤖 GitLab Bot 🤖