Review Pinia and legacy Vuex state-store code for the security-critical defect classes that\nare specific to state stores as a component — not general Vue architecture, not composable\ndesign, and not SSR hydration/injection issues that belong to vue-ssr-security-review. This\nskill exists to keep the review anchored to five documented defect classes: (a) sensitive data\npersisted client-side without scoping, (b) store hydration from an untrusted server payload\nwith un-escaped serialization, (c) SSR store-singleton cross-request pollution, (d) store\nplugins/hooks acting on untrusted payloads and client-held flags used as an authorization\nsource of truth, and (e) devtools state exposure in production. It does not re-litigate\ngeneral reactivity/composable architecture, v-html/URL-injection review (covered by\nvue-ssr-security-review), or Composition API design quality (covered by\nvue-composition-api-architecture-review) in every response.
Use this skill when the user asks to:
\ndefineStore) or a legacy Vuex module/store for security\nissues,pinia-plugin-persistedstate / vuex-persistedstate configuration is safe\n(what gets persisted, and where),entry-server.js, a Nuxt server plugin, an\nExpress/Node handler that constructs createPinia()/createStore()) for cross-request\npollution risk,$subscribe/$onAction hook, or Vuex plugin that consumes\nmutation/action payloads,isAdmin, role) is being trusted\nas an authorization boundary,Do not use this skill for:
\nv-html/dynamic-URL injection review or SSR entry-point app/router creation — use\nvue-ssr-security-review for those; this skill covers the store specifically, not the\nbroader SSR rendering surface (load both skills together if the review spans both),vue-composition-api-architecture-review instead,state-management-decision-review instead,resolve-library-id before citing any store-behavior claim. This\nskill's three grounding libraries: /vuejs/pinia (Pinia core — SSR hydration, plugins,\n$subscribe/$onAction), /prazdevs/pinia-plugin-persistedstate (persistence defaults and\npick/storage config), /vuejs/vuex (legacy Vuex — state as function, devtools\noption, plugin/module API).query-docs against /prazdevs/pinia-plugin-persistedstate to confirm persistence\ndefaults before flagging a persistence config: storage defaults to localStorage when\nunset; pick (an array of dotted state-path strings) restricts persistence to named paths;\nwith no pick, the entire state is persisted. Cite these as documentation-based.query-docs against /vuejs/pinia to confirm SSR hydration mechanics before flagging a\nhydration finding: the documented client-side pattern is\npinia.state.value = JSON.parse(window.__pinia), and Pinia's own SSR guide states escaping\nthe serialized state is \"VERY important if the content of the state can be changed by\nthe user, which is almost always the case,\" recommending devalue (or equivalent) over naive\nJSON.stringify. Cite as documentation-based.query-docs against /vuejs/pinia to confirm $subscribe/$onAction hook signatures\n(mutation object with type/storeId/payload; action object with name/store/args/\nafter/onError) before describing a plugin-hook finding — do not invent a hook name or\nargument Context7 does not confirm.query-docs against /vuejs/vuex to confirm the state: () => ({...}) factory pattern\n(module reusability without shared state) and the devtools: boolean store option before\nciting either — do not assume Pinia has an equivalent devtools boolean on defineStore/\ncreatePinia; Context7 does not confirm that API surface for Pinia, so any Pinia-devtools\nconcern must be scoped to \"a build-time devtools plugin explicitly force-enabled in\nproduction,\" not a Pinia store option, and labeled inference unless a repo-specific config\nis found.package.json first to confirm which store library is in play (pinia,\npinia-plugin-persistedstate, vuex, vuex-persistedstate) and its major version — API\nnames and defaults differ between Pinia and Vuex and across Vuex 3/4; do not apply one\nlibrary's API names to the other.official_docs URLs in this skill's\nmetadata.json and label the claim documentation-based, unverified against current release.persist/pick/storage config, the specific module-scope createPinia()/createStore()\ndeclaration, or the specific untraced payload sink is not a valid finding — it is a guess.state() shape and the full persist\nconfig together. A persist: true (or persist: {}) with no pick/paths array persists\nthe entire state — treat every sensitive field in that state as persisted unless a pick\nlist demonstrably excludes it. A pick list that omits the sensitive field(s) clears the\nfinding for those fields specifically (not for the whole store, if other sensitive fields\nremain unscoped).vue-ssr-security-review requires for app instances: is the createPinia()/\ncreateStore() call inside the per-request handler, and does that handler close over any\nmodule-scope mutable/reactive reference? An immutable module-scope constant (a frozen config\nobject, a static route table) is not the risk; a store instance or mutable cache is.isAdmin, role, permissions) as an\nauthorization boundary for a mutating action unless the review also confirms (via visible\nserver-side code, or an explicit statement that server-side authorization is out of scope for\nthis static review) that the actual mutation is re-checked server-side. A store flag gating\nonly UI visibility (hiding a button) is not itself a finding; a store flag gating whether a\nmutating network call is made is a finding regardless of UI-layer intent, because the flag\nis client-writable.$subscribe/$onAction/Vuex-plugin hook as risky. Only hooks that act on\nthe payload with a side effect (write, external call, log of sensitive data, mutate another\nstore) and lack payload validation are findings; read-only observation (e.g., analytics event\nnaming) is not.Load these only when needed:
\npinia-plugin-persistedstate/vuex-persistedstate configuration, SSR store\ncreation/singleton risk, or server-payload hydration (window.__pinia/__INITIAL_STATE__).$subscribe/$onAction/Vuex-plugin hooks, client-held role/permission\nflags used for access control, or devtools production exposure.Return, at minimum:
\npersistence, hydration,\nssr-pollution, untrusted-payload, client-auth-flag, or devtools-exposure), the\nconcrete data-flow trace (state field → persist config, or server payload → hydration call,\nor module-scope declaration → per-request reachability, or payload → sink), and a fix sketch\nmatching the grounding library's documented pattern,pick/paths (if any) and which are not,repo evidence, documentation-based, or inference), with\nstructural risk findings explicitly labeled as structural risk, not as confirmed-exploited,vue-ssr-security-review\").