You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's currently unclear what kind of base64 decoding is used and what kind of restrictions are enforced.
From code inspection in WebKit it appears that both base64 and base64url decoding are attempted, both without enforcing padding restrictions. That doesn't strike me as great from a security perspective. If we could model it as instead as encoding and then comparing for strict equality that would be vastly preferable, but there are some tests that would be impacted by this.
Let's track this part of #84 separately.
It's currently unclear what kind of base64 decoding is used and what kind of restrictions are enforced.
From code inspection in WebKit it appears that both base64 and base64url decoding are attempted, both without enforcing padding restrictions. That doesn't strike me as great from a security perspective. If we could model it as instead as encoding and then comparing for strict equality that would be vastly preferable, but there are some tests that would be impacted by this.
Corresponding CSP issue: w3c/webappsec-csp#423.
The text was updated successfully, but these errors were encountered: