
* Move metadata to root * Define S6105 for JS/TS * Move message.adoc * Fix incorrect autolink * Fix standards header * Add "noncompliant" to code sample * Change header styling * Apply suggestions from code review Co-authored-by: gaetan-ferry-sonarsource <112399173+gaetan-ferry-sonarsource@users.noreply.github.com> * Update rules/S6105/common/fix/how-does-this-work.adoc Co-authored-by: gaetan-ferry-sonarsource <112399173+gaetan-ferry-sonarsource@users.noreply.github.com> * Update rules/S6105/common/pitfalls/starts-with.adoc Co-authored-by: gaetan-ferry-sonarsource <112399173+gaetan-ferry-sonarsource@users.noreply.github.com> * Remove reference to javascript pseudo-protocol * Update rules/S6105/common/fix/how-does-this-work.adoc Co-authored-by: gaetan-ferry-sonarsource <112399173+gaetan-ferry-sonarsource@users.noreply.github.com> * Rewrite startsWith text * Change framework name Co-authored-by: gaetan-ferry-sonarsource <112399173+gaetan-ferry-sonarsource@users.noreply.github.com>
10 lines
809 B
Plaintext
10 lines
809 B
Plaintext
=== How does this work?
|
|
|
|
Most client-side frameworks, such as `Vue.js` or `React.js`, provide built-in redirection methods. Those should be preferred as they often provide additional security mechanisms. However, these built-in methods are usually engineered for internal page redirections. Thus, they might not solve the reader's use case.
|
|
|
|
In case the application strictly requires external redirections based on user-controllable data, the following should be done instead:
|
|
|
|
1. Validating the `authority` part of the URL against a statically defined value (see Pitfalls.)
|
|
2. Using an allowlist approach in case the destination URLs are multiple but limited.
|
|
3. Adding a dynamic confirmation dialog, warning about the imminent action and requiring manual authorization to proceed to the actual redirection.
|