-
Notifications
You must be signed in to change notification settings - Fork 17
Security Considerations: Writing first round of threats and mitigatio… #277
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
…ns (Web API level) A first draft of the identified threats and potential mitigations (some already applied), particularly at the Web API level. *Threats* - SOP Violation - Fingerprinting and Cross-Device Tracking - Cross Site Scripting (XSS), Cross Site Request Forgery (CSRF) - Clickjacking & UI redressing - Reply Attack - Quishing - Phishing/Harvesting *Mitigations (already implemented or to be considered)* - Data Minimization - Secure contexts - Limit API usage - Informing the user - Transient activation Things to consider: - What else could go wrong (if there are other threats) - What can we do about the threats we have identified - Do we like the countermeasures we already have in place - Are there other mitigations to consider or write down [cc'ing @Sh-Amir and @ZAnsaroudi]
<h3 id='threats-and-attacks'>Threats and Attacks</h3> | ||
<h4 id='same-origin-policy-violations'>Same-Origin Policy Violations</h4> | ||
<p>SOP violation occurs when a script or resource from one origin breaks the browser's foundational Same-Origin | ||
Policy—intended to segregate data between origins—by accessing or tampering with another origin's data, cookies, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Policy—intended to segregate data between origins—by accessing or tampering with another origin's data, cookies, | |
Policy, which is intended to segregate data between origins, by accessing or tampering with another origin's data, cookies, |
This still feel overly broad and not necessarily related to the API. |
|
||
</ul> | ||
<h4 id='transient-activation'>Transient activation</h4> | ||
<p>Transient activation ensures that powerful or sensitive web features can only be triggered immediately following a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This redefines "transient activation", which is not appropriate. This should only say, "The API relies on transient activation, preventing websites from calling the API without user interaction."
data sharing or unintended leaks.</p> | ||
<p>The API prompts the user to show the request's origin before proceeding.</p> | ||
<h4 id='permission-request'>Permission request</h4> | ||
<p>Permission controls require explicit user permission before any API use is allowed. This ensures that users know when |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not true. This should be removed. There is no permission screen.
We rely on Permission Policy only. And only to prevent third-party iframes from calling the API.
…ns (Web API level)
A first draft of the identified threats and potential mitigations (some already applied), particularly at the Web API level.
Threats
Mitigations (already implemented or to be considered)
Things to consider:
[cc'ing @Sh-Amir and @ZAnsaroudi]
Preview | Diff