A Vue app can pass its UI tests while sending personal data to an analytics script, leaving a session token readable by JavaScript, or exposing private text in an error report. I would treat those as release blockers, even for a small app, because the browser’s data paths matter more than the neatness of its components.
A tidy Vue component cannot tell you where user data goes
Vue.js Development Best Practices for Modern Web Apps is worth reading alongside a data-flow diagram, because component-level guidance cannot show every service that receives a user’s information. Start with one ordinary action, such as opening a profile page. List the data returned by the API, each Vue 3 component that renders it, any Pinia 3 store that retains it, and every network request triggered by the page. Include scripts loaded through a tag manager: they run in the browser whether or not your Vue code imports them.
That exercise often changes what “safe to display” means. A profile name rendered with Vue’s text interpolation is escaped by Vue, but the same name may still enter an analytics event, a URL, or an error report if your code sends it there. Escaping addresses one route to script injection; it does not grant permission to share the value. Before adding an event property, ask whether the event needs that property at all. “Profile opened” may answer the product question without an email address or account name.
I would not load a third-party analytics script before consent merely because the dashboard does not yet identify users; the script can still make a network request and receive browser metadata before the person has made a choice. A first-party event endpoint and a third-party analytics script are different options. The first-party endpoint wins when you need tighter control over collection and retention, but it costs engineering time and does not become private automatically. The third-party script wins when the team needs a managed reporting interface quickly, but it costs direct control over what the browser sends and what the vendor retains. Inspect actual requests in browser developer tools rather than inferring behavior from a vendor’s setup page.
Make the diagram testable. In Playwright, visit the page before the consent action and record requests to analytics hosts; a request-count target of zero before consent is a release criterion to verify, not a claim about your current app. Then repeat after consent and after withdrawal. Check the Network panel with an authenticated profile open, because a request that looks harmless on a blank landing page may acquire identifying properties after login. If the site honors Global Privacy Control, document how that signal changes collection; do not assume a consent banner handles it without testing its configuration.
Keeping session tokens out of JavaScript is worth the extra CSRF work
Putting an access token in localStorage makes it easy to attach an Authorization header from Vue, but any script running in that origin can read the token. That includes code reached through an injection flaw or a compromised dependency. For a browser-only app with a same-origin backend, I would usually prefer a server-managed session cookie marked HttpOnly, Secure, and SameSite=Lax, because JavaScript cannot read an HttpOnly cookie even though the browser can send it with requests.
That choice has a cost: cookies can be sent automatically, so state-changing requests need a CSRF defense. Use an anti-CSRF token or a server-enforced Origin check suited to your deployment, and test cross-site requests; SameSite=Lax is useful defense in depth, not a substitute for understanding your request paths. An OAuth 2.0 Authorization Code flow with PKCE can win instead when a browser client must call a separate API under a supported identity design, but it brings token-lifetime and storage decisions that a same-origin session can avoid. Do not choose either option solely because a Vue authentication tutorial has fewer lines of code.
A component should request only the data it needs and avoid persisting the response as a convenience. This Vue 3 single-file component expects GET /api/profile to return JSON containing an email field; the server must still authorize the request and set appropriate cache headers:
<script setup>
import { ref } from 'vue'
const email = ref('')
async function lookup() {
const response = await fetch('/api/profile', { credentials: 'same-origin' })
if (!response.ok) throw new Error('Profile request failed')
email.value = (await response.json()).email ?? ''
}
</script>
<template>
<button type="button" @click="lookup">Load profile</button>
<p>{{ email }}</p>
</template>
The button makes the request deliberate, and Vue interpolates the returned text rather than treating it as HTML; neither property prevents another script from reading text already present on the page. If the server sends sensitive profile responses, Cache-Control: no-store is an appropriate setting to evaluate because it tells caches not to store those responses. Clear Pinia state on logout as well, because removing a cookie does not erase data already held in a running tab. For a session timeout, 15 minutes of inactivity is a value to tune against the app’s risk and usability, not a universally safe default.
Rich text turns a harmless-looking prop into a trust decision
Vue’s {{ value }} interpolation escapes HTML, while v-html asks the browser to parse it. That difference matters when a product request changes a plain-text comment into “formatted notes.” I would not replace interpolation with v-html and promise to sanitize later, because the first untrusted payload can reach users before that later task is finished. If formatting is genuinely required, define which tags and attributes are allowed, sanitize with a maintained library such as DOMPurify 3, and test the rendered result with hostile inputs.
Sanitizing in one place is not permission to ignore the other boundaries. A Content Security Policy using the CSP Level 3 script-src directive can limit where scripts load from, but it does not make unsafe HTML desirable; an injection may still alter what users see or submit. Trusted Types can add a browser-enforced check around dangerous DOM sinks where supported, but it requires policies and testing rather than a flag copied into production. Use CSP reports to discover violations before tightening enforcement, and review any exception such as 'unsafe-inline' because an exception can undercut the restriction you meant to add.
I would challenge Vue.js Development Best Practices for Modern Web Apps with one additional review question: “What untrusted value crosses into a browser parsing context?” That question catches more than v-html. Check URL construction, links opened with target="_blank", and data passed to chart or editor libraries, because each library may interpret strings differently. Vue Router 4 guards can control navigation in the UI, but they cannot authorize an API response; the server must check access on every protected request because a user can call the endpoint without using the router.
Dependencies deserve the same boundary thinking. Vite 6 can make adding a package feel cheap, but a package’s browser code executes with the page’s privileges once bundled. Use a lockfile, review major dependency changes, and run npm audit as a signal to investigate rather than proof of safety; its advisories cannot tell you whether a package sends private data in normal operation. For third-party scripts loaded from a fixed URL, Subresource Integrity can detect unexpected file changes, although it is awkward when a vendor changes the script frequently. A proposed review trigger of one newly added browser-executed vendor per pull request keeps the decision visible without pretending every dependency carries equal risk.
Useful error reports should collect less than developers want
When an error occurs only for one user, sending the whole application state to Sentry feels helpful because it might reproduce the failure. It can also copy profile fields, draft text, or API responses into another system. Configure beforeSend to remove known sensitive fields, turn off session replay until its masking behavior has been verified, and generate a test error while logged in. Inspect the stored event itself; reading the configuration is not evidence that the resulting payload is clean.
There is a real trade-off. Full replay wins when an interaction is difficult to reproduce and the captured data is acceptable to collect, but it costs storage, review effort, and exposure if masking misses a field. Redacted errors plus deliberately named events win when users handle sensitive text, but they cost debugging detail. For an initial rollout, 2% of eligible sessions is a sampling rate to experiment with after consent and masking tests, not a privacy guarantee: a small sample can still contain one person’s private message.
Set retention deliberately, too. 30 days is an example policy for debugging events that a team should justify against its support window and obligations; “keep everything” is not a neutral default because old events remain available long after their diagnostic value fades. Check the vendor’s published retention and deletion controls against your configured policy. Give production error access only to people who need it, and remove direct identifiers from alert titles because alerts may be forwarded into chat, email, and ticket systems.
Finally, test privacy behavior as behavior. A Playwright test can assert that a profile email is absent from analytics request bodies and URLs, while a separate test verifies that logout removes it from visible Pinia-backed views. Use the OWASP Application Security Verification Standard as a source of verification questions, then write app-specific assertions for the paths you actually have. A passing unit test for a Vue component cannot establish what a third-party script received over the network; an observed request can.
The first fix is to trace one private value
Pick one real profile field and follow it from the API response through the Vue page, browser storage, network requests, and error reporting. Record each destination and who can access it. Then remove one unnecessary destination before adding another security package. That small trace gives your next code review a concrete question: where could this value leave the page without the user expecting it?
