Skip to content

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.

Sign up for GitHub

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

Open
wants to merge 8 commits into
base: main
Choose a base branch
from
Open

Security Considerations: Writing first round of threats and mitigatio… #277

Changes from all commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
4f3cadf
Security Considerations: Writing first round of threats and mitigatio…
simoneonofri Jun 16, 2025
6c31c56
Update index.html
simoneonofri Jun 23, 2025
14f2526
Update index.html
simoneonofri Jun 23, 2025
f89076d
Update index.html
simoneonofri Jun 23, 2025
fc7d8fa
Update index.html
simoneonofri Jun 23, 2025
c65ca41
Update index.html
simoneonofri Jun 23, 2025
31b1b9a
Update index.html
simoneonofri Jun 25, 2025
3dc5e39
Merge branch 'main' into simoneonofri-patch-1
marcoscaceres Jul 7, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
125 changes: 125 additions & 0 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1079,6 +1079,131 @@ <h3>
the session management utilized on the website.
</p>
</section>
<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, which is intended to segregate data between origins, by accessing or tampering with another origin's data, cookies,
DOM, or authenticated sessions.</p>
<h4 id='fingerprinting-and-cross-device-tracking'>Fingerprinting and Cross-Device Tracking</h4>
<p>Fingerprinting and Cross‑Device Tracking occur when the Digital Credentials API (or its surrounding browser features)
exposes minute but identifiable configuration details—like supported protocols, hardware capabilities, or timing
behaviors—that can be collected over time to create a unique fingerprint for a device, user, or browser.</p>
<p><strong>Mitigations</strong></p>
<ul>
<li>Data Minimization</li>

</ul>
<h4 id='cross-site-scripting-xss-cross-site-request-forgery-csrf'>Cross-Site Scripting (XSS), Cross-Site Request Forgery
(CSRF)</h4>
<p>XSS occurs when an attacker injects malicious JavaScript into a web page, enabling that script to silently call the
API within the context of a trusted site.</p>
<p>CSRF occurs when a malicious site tricks the user’s browser into sending a silent request to the API on a legitimate,
origin using hidden forms, images, or fetch calls to forge credential retrieval action.</p>
<p><strong>Mitigations</strong></p>
<ul>
<li>Transient activation (Web API level) </li>
<li>Permission (Web API level) </li>
<li>Content Security Policy (RP level)</li>

</ul>
<h4 id='clickjacking--ui-redressing'>Clickjacking &amp; UI redressing</h4>
<p>Clickjacking occurs when an attacker invisibly overlays a credential request prompt behind UI elements, tricking
users into approving unwarranted credential sharing.</p>
<p><strong>Mitigations</strong></p>
<ul>
<li>Transient activation (Web API level) </li>
<li>Informing the user (Web API level) </li>
<li>Content Security Policy (RP level)</li>

</ul>
<h4 id='man-in-the-middle'>Man-In-the-Middle</h4>
<p>MiTM occurs when attackers insert themselves into the communication channel between two parties, intercepting,
relaying, or modifying messages at lower layers (like network or transport). At the same time, both endpoints
believe they are talking directly to each other.</p>
<p><strong>Mitigations</strong></p>
<ul>
<li>Secure contexts (Web API level) </li>
<li>Encryption (Protocol level) </li>
<li>Signature (Protocol level) </li>
<li>Nonce (Protocol level)</li>

</ul>
<h4 id='reply-attack'>Replay Attack</h4>
<p>Replay Attacks occur when an attacker intercepts a legitimate credential exchange (via same- or cross-device flows)
and later replays that same exchange to another party. This tricks systems into accepting old, valid credentials as
fresh, leading to unauthorized authentication or credential disclosure.</p>
<p><strong>Mitigations</strong></p>
<ul>
<li>Secure contexts (Web API level) </li>
<li>Nonce (Protocol level)</li>

</ul>
<h4 id='quishing'>Quishing</h4>
<p>Quishing occurs when a malicious site tricks the user into replacing a legitimate QR code, tricking it into
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand "replacing" here. It seems like the attack is presenting the user with a maliciously-crafted QR code which when followed, will lead to a credential presentation request that will deliver the results to an unexpected party (either the attacker, or as a confused deputy confirming the user's identity for a request that the attacker made to some other verifier). Maybe the attacker is inserting it in a place where it looks to the user like a legitimate request from a different verifier, and that's a kind of replacement?

Copy link
Contributor Author

@simoneonofri simoneonofri Jun 23, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the framing I was giving it, the QR code is managed directly by the API and displayed securely and not via an (controlled by an adversary).

Does that make sense to you, or do you think we should frame it differently?

generating a Verifiable Presentation for an unauthorized verifier, enabling impersonation or unauthorized access to
services or data.</p>
<h4 id='phishingharvesting'>Phishing/Harvesting</h4>
<p>Phishing/Harvesting occurs when a malicious site tricks users into sharing credentials by imitating a legitimate
relying party, potentially harvesting sensitive identity data.</p>
<h3 id='mitigations'>Mitigations</h3>
<h4 id='data-minimization'>Data Minimization</h4>
<p>Data Minimization occurs when the API restricts the information shared to only what’s necessary for each credential
operation. Such operations must expose the smallest possible dataset—aligned with the specific purpose the user
explicitly approved—while concealing any additional metadata or details about why data isn't available.</p>
<p>The API uses the same message if the response is unavailable because of software or hardware limitations, user
permission, or credentials, ensuring that this lack of availability cannot be used to infer device —or user-specific
information.</p>
<p><strong>Threats and Attacks</strong></p>
<ul>
<li>Fingerprinting and Cross-Device Tracking </li>

</ul>
<h4 id='explicitly-restrict-the-feature-to-first-party-origins'>Explicitly restrict the feature to first-party origins.
</h4>
<p>Limiting this sensitive API to only first-party contexts, where the requesting origin matches the top-level site,
makes it possible to block third-party content (like ads or embedded widgets) from invoking credential operations.
This prevents untrusted embedded code from accessing or misusing digital credentials under your site's permission
and control.</p>
<p>The API is not available to third-party iframes without a permission policy.</p>
<h4 id='secure-contexts'>Secure contexts</h4>
<p>Secure contexts ensure that certain powerful or privacy-sensitive web features are only offered when pages are loaded
over authenticated, encrypted channels (e.g., HTTPS, or other “potentially trustworthy” schemes like file:// or
localhost), blocking access from insecure origins.</p>
<p>The API is only available in a secure context.</p>
<p><strong>Mitigates</strong> </p>
<ul>
<li>MiTM attacks</li>

</ul>
<h4 id='limit-api-usage'>Limit API usage</h4>
<p>Implementing multi-layered rate-limiting is essential to prevent API abuse, ensure reliability, and prevent
credential-related attacks.</p>
<p><em>Global</em>: A global rate limit should be implemented to restrict the number of requests made within a certain
period (e.g., per minute or hour), preventing excessive use and over-asking<br /><em>Session-Based</em>: Set
session-based limits during a single-user session to prevent prolonged abuse.<br /><em>Origin-based</em>: per site
and subdomains</p>
<h4 id='informing-the-user'>Informing the user</h4>
<p>When handling sensitive API calls involving personal data or credentials, including explicit user approval at the
point of use is important. Instead of allowing background or automated exchanges, the user agent must present a
clear, interactive prompt, such as a chooser UI, that shows the requesting origin and the data being accessed. This
ensures users are fully informed and retain control over each operation, significantly reducing risks from silent
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 Policy</h4>
<p>Permission policy allows developers to selectively enable and disable use of various browser features and APIs.</p>
<p>This API defines a <a href="#permissions-policy">policy-controlled feature</a>, to prevent third-party iframes from calling the API.</p>
<p><strong>Threats and Attacks</strong></p>
<ul>
<li>Fingerprinting and Cross-Device Tracking</li>

</ul>
<h4 id='transient-activation'>Transient activation</h4>
<p>The API relies on <a href="https://html.spec.whatwg.org/multipage/interaction.html#transient-activation">transient activation</a>, preventing websites from calling the API without user interaction.</p>
<p><strong>Threats and Attacks</strong></p>
<ul>
<li>Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF)</li>

</ul>
</section>
<section class="informative">
<h2>
Expand Down