> ## Documentation Index > Fetch the complete documentation index at: https://docs.dakota.xyz/llms.txt > Use this file to discover all available pages before exploring further. # Cards.js Security > How Cards.js keeps card data out of your reach, what stays your responsibility, and how to report a vulnerability **Cards is available in sandbox only while we finish development.** Dakota enables Cards per account. The Cards endpoints are in the [API reference](/api-reference/introduction), marked **Sandbox only**. Endpoints, fields, and flows can still change before release. Cards.js is built so that your app displays sensitive card data without that data ever being exposed to your app. This page explains the guarantees that follow from that, the responsibilities that stay with you, and how to report a vulnerability. ## Card data is never in your reach The full PAN, CVV, and expiry render inside frames that Dakota's card-data processor controls. Those frames are cross-origin: **your JavaScript, your servers, and Dakota's own application code cannot read their contents.** Your page positions and sizes the frames and styles their text, but the values themselves live only inside the frames, and they go straight from the card-data processor to the cardholder's screen. The sensitive values never touch your DOM, your network, or your storage, so integrating Cards.js keeps your web front end within **PCI DSS SAQ A** scope. ## Deliberate reveal Details show only on an explicit action, and only briefly: * **Single-use sessions.** A session authorizes one reveal and is consumed by it. There is no reusable, long-lived credential in the browser. Each reveal mints a fresh session. * **A bounded reveal window.** A successful reveal is time-boxed. The window is the smaller of any `autoMaskMs` you set and the session's time-to-live, and the TTL is itself capped at 10 minutes. Details cannot stay revealed indefinitely. * **SDK-enforced re-mask.** When the window ends, the SDK tears down the value frames and restores the masked face itself. It does not depend on your code to hide the data again. ## Your backend mints, the browser consumes Your API key stays on your server, which mints each session only for a card the signed-in user owns. The browser only ever holds a single-use session token. See [Secure card data](/documentation/cards/secure-card-data#mint-a-reveal-session). ## Keep session tokens out of your telemetry The card-data processor's frames receive the session token in their URL, as a `session` query parameter. The SDK never logs the token, but tools on your page that record resource or frame URLs can capture it: real-user monitoring, session replay, and error tracking. Configure those tools to drop or redact the `session` parameter for the frame origins listed in [Network & CSP](/documentation/cards/cards-js/network-and-csp). ## No telemetry Cards.js makes no network calls except those required to display card data: it loads the card-data processor's reveal frames. It ships **no analytics and no error reporting**, and it **never logs session tokens**. The library sends nothing about your cardholders or your integration anywhere. ## Reporting a vulnerability We take the security of Cards.js seriously. If you believe you have found a vulnerability, report it to us privately, so that we can investigate and fix it before it is publicly disclosed. Email **[security@dakota.xyz](mailto:security@dakota.xyz)** with: * a description of the issue and its potential impact, * the affected version(s) of `@dakota-xyz/cards-js`, * steps to reproduce, or a proof of concept, if you have one. **Do not** open a public issue, pull request, or discussion for a suspected vulnerability, and do not disclose it publicly until we have had a reasonable opportunity to respond. ### What to expect We will acknowledge your report, keep you informed as we investigate, and tell you when a fix is available. We ask that you give us a reasonable window to fix the issue before any public disclosure, and that your testing does not access, modify, or exfiltrate data that is not yours. This project does not operate a paid bug-bounty program, and no bounty or reward is promised for a report. We are grateful for responsible disclosure regardless.