LEGACY Vue 3 + Vite UI prototype for the vendor portal — static mockup, no backend, no auth. Superseded by alist-vendors (Next.js).
alist-vendors (Next.js, last commit Nov 2025). No commits here since 2024-05-15. Treat as historical reference; do not ship features here without explicit stakeholder confirmation.package.json is alistbussinessdashboard (sic).src/ (no fetch, no axios). No .env file, no VITE_* usage. Every list, table, and chart is hard-coded mock data — which caps real-world exploitability, because there is no live backend or real data to compromise.LoginView.vue's sign-in button is a <RouterLink to="/">. No credentials are sent, no token is stored, no route guard exists in router/index.js.ScanVoucherView.vue:33 hard-codes 'ALISTY2K002' as the only valid voucher — the QR scanner runs client-side with no server verification.vue-file-upload@0.1.12 drags EOL vue@2.7.16 into the build tree; Vite 5.2.9 / esbuild 0.20.2 / braces / nanoid carry known 2024-2025 CVEs — all developer/build-time rather than production exposure.alist-vendors.| Category | Technology | Version | Notes |
|---|---|---|---|
| Framework | Vue | 3.4.23 (Composition API, <script setup>) | One file (App.vue) mixes Composition + Options API; EOL Vue 2.7.16 also nested via an abandoned dep (see AVP-03) |
| Build | Vite | 5.2.9 (declared ^5.2.8) | Plus @vitejs/plugin-vue-jsx and vite-plugin-vue-devtools (registered unconditionally); 5.2.x carries the 2024-2025 dev-server CVE family (AVP-04) |
| Routing | vue-router | 4.3.2 | 12 routes, history mode, no auth guard — beforeEach only scrolls to top |
| State | none | — | No Pinia/Vuex. Single localStorage write in CardDetails.vue (UI state only, no token) |
| UI kit | Bootstrap | 5.3.3 | Loaded async via import('bootstrap/dist/js/bootstrap.bundle.js') in main.js |
| Styling | SCSS | sass 1.75 (Dart) | Tokens in src/assets/styles/; custom ts-* class prefix. Note: a phantom npm scss@0.2.4 dep is unused (AVP-11) |
| File upload | vue-filepond | 7.0.4 / filepond 4.31 | 5 components wire FilePond with server="/api" (a dead endpoint); label-idle is a raw-HTML innerHTML sink — latent only (AVP-06) |
| QR / voucher | vue-qrcode-reader | 5.5.4 | Used by ScanVoucherView; @detect handler is undefined (dead QR path) so validation is a client-side string compare (AVP-02) |
| Charts | apexcharts / vue3-apexcharts | 3.49 / 1.5 | All chart data hard-coded in component templates |
| Media / misc | video.js, @fancyapps/ui, swiper | 8.12 / 5.0 / 11.1 | Galleries and post previews on campaign pages |
| Tests | Vitest + @vue/test-utils + jsdom | 1.4 / 2.4 / 24 | Exactly one spec: HelloWorld.spec.js (untouched template) |
| Lint / format | ESLint + Prettier | 8.57 / 3.2 | Config present, no CI hook discovered (AVP-13) |
Classic Vite SPA shell: main.js creates the Vue app, installs the router, and mounts to #app. App.vue renders a Navbar + Sidebar chrome around <RouterView />, suppressing the chrome on /signin and /Billing. There is no API client, no store, no auth layer, and no environment-driven configuration — this is a presentation-only codebase. The absence of a server trust boundary is the single biggest mitigant on every finding below: there is nothing behind the UI to actually defraud today.
This is a white-box static review of alist-vendor-portal conducted as part of the May 2026 A-List engagement. Four frontend assessment dimensions were applied — client-side secret exposure, client auth/token handling, client-side injection (XSS), and dependency / supply-chain — each grounded in the anthropic-cybersecurity-skills playbooks (which encode OWASP WSTG / API Top 10 / CWE detection methodology) and adapted to source review. Overlapping scanner findings were deduplicated into canonical entries, then adversarially re-verified against the actual source and lockfile; every finding below is rated confirmed, scored with CVSS 3.1, and mapped to OWASP Top 10 2021 + CWE.
implementing-secret-scanning-with-gitleaks testing-for-sensitive-data-exposure performing-cryptographic-audit-of-applicationtesting-jwt-token-security testing-api-authentication-weaknesses testing-oauth2-implementation-flawstesting-for-xss-vulnerabilities exploiting-prototype-pollution-in-javascript testing-for-open-redirect-vulnerabilitiesperforming-sca-dependency-scanning-with-snyk analyzing-sbom-for-supply-chain-vulnerabilities detecting-supply-chain-attacks-in-ci-cd prioritizing-vulnerabilities-with-cvss-scoring
alist-vendor-portal is a LEGACY, backend-less Vue 3 + Vite UI prototype (last commit 2024-05-15, superseded by the active alist-vendors Next.js portal) — there is no server, no API client, no database, and no real data in this codebase, which substantially caps real-world exploitability. The dominant design issues are an entirely fake authentication layer (the "Sign in" button is a RouterLink, credentials are never bound or transmitted, and no route is guarded) and a voucher "redemption" that is a hard-coded client-side string-equality check against the shipped secret ALISTY2K002; both are confirmed and would be serious if this pattern or these values were carried into the successor or if a static build were hosted unprotected. The supply chain is the other concern: an abandoned, unused vue-file-upload@0.1.12 permanently drags EOL Vue 2.7.16 + @vue/compiler-sfc 2.7.16 into the install tree, and the build toolchain (Vite 5.2.9, esbuild 0.20.2, braces 3.0.2, nanoid 3.3.7) carries known 2024-2025 CVEs — all developer/build-time rather than production exposure, since the shipped artifact is a static Vue 3 bundle. Remaining findings (hard-coded promo code and beneficiary banking details, console-logged voucher input, unguarded VueDevTools, latent FilePond innerHTML sink, phantom scss/ometa deps, no CI/SCA) are hygiene/regression-prevention items. Overall risk is rated high on the strength of the secrets-in-git and design-auth findings per the engagement weighting, but the practical urgency is mitigated by the repo being retired — the correct disposition is to archive it and ensure none of these patterns are inherited by alist-vendors.
| Category | Status | Notes |
|---|---|---|
| A01:2021 Broken Access Control | Vulnerable | No route guards and no auth state; every route directly addressable (folded into AVP-01). |
| A02:2021 Cryptographic Failures | Vulnerable | Hard-coded secrets shipped in bundle/git: voucher code (AVP-02), promo code (AVP-07), beneficiary banking details (AVP-09). |
| A03:2021 Injection | Partial | FilePond label-idle is an innerHTML sink but all values are static literals — latent only, no live injection path (AVP-06); no v-html/eval anywhere in src/. |
| A04:2021 Insecure Design | Partial | Client-side-only trust decisions (fake auth, client voucher check) are insecure-by-design patterns; captured under AVP-01/AVP-02. No threat model for a prototype. |
| A05:2021 Security Misconfiguration | Vulnerable | VueDevTools registered unconditionally (AVP-10); no Content-Security-Policy in index.html (verified absent). |
| A06:2021 Vulnerable and Outdated Components | Vulnerable | EOL Vue 2.7.16 via abandoned vue-file-upload (AVP-03); Vite 5.2.9 (AVP-04); esbuild 0.20.2 (AVP-05); braces/nanoid (AVP-12); phantom scss/ometa (AVP-11); no SCA gate (AVP-13). |
| A07:2021 Identification and Authentication Failures | Vulnerable | No authentication whatsoever — decorative login, no session/token lifecycle, inert logout (AVP-01); client-side voucher "auth" (AVP-02). |
| A08:2021 Software and Data Integrity Failures | Partial | Install-time scripts (esbuild hasInstallScript) run unpinned with npm install and no npm ci/lockfile-integrity gate (noted in AVP-05/AVP-13); no SRI on assets, but no external CDN script tags in index.html either. |
| A09:2021 Security Logging and Monitoring Failures | Vulnerable | Leftover console.log statements leak the entered voucher code and payment state to the browser console (AVP-08); no real logging/monitoring (expected for a frontend prototype). |
| A10:2021 Server-Side Request Forgery (SSRF) | N/A | No server, no backend, and zero outbound HTTP calls in src/ (no fetch/axios/XHR) — no SSRF surface. |
The application has no authentication layer of any kind. The login screen is purely cosmetic: the credential inputs are unbound (no v-model) and the "Sign in" button is a vue-router <RouterLink to="/"> that simply navigates to the dashboard. There is no auth state, identity provider, token issuance, session, or storage anywhere. The single global navigation guard only resets scroll and always calls next(), so every route (/, /Billing, /team, /scan-voucher, /campaigns, /plans, ...) is directly addressable by any anonymous visitor. The displayed "Admin" role and the "Sign out" controls are static template artifacts with no backing logic. This is a backend-less static prototype, so there is no server trust boundary to compensate — but equally there is no real data or backend to compromise; the risk materializes only if a built bundle is hosted and (in a successor) wired to a real API.
/team, /Billing directly) and land in the full vendor dashboard. They read the bank-transfer beneficiary details, the promo code, and the voucher success UI, and can drive every flow the UI exposes — there is no session, guard, or server check to stop them.If a vite build of this prototype is hosted on a reachable URL, every "protected" vendor screen (team management, billing/bank-transfer flow, campaign creation, voucher redemption UI) is open to any anonymous user with no credential whatsoever. Because the app is frontend-only with hard-coded mock data, no real records are exposed today; the principal danger is that the no-auth pattern (and its UI implying an auth flow that does not exist) gets carried into the active alist-vendors successor or misleads stakeholders during demos. Rated P1 as a design-level auth failure rather than P0 because there is no live backend behind it.
HttpOnly+Secure+SameSite cookie (never localStorage), add a global router guard that checks a server-validated session and redirects unauthenticated users to /signin, tag protected routes with meta.requiresAuth, and — critically — enforce authn/authz server-side on every data endpoint (never trust a client-rendered "Admin" label or client route guard).Merged three overlapping scanner findings (no-auth login, no route guards, no session/token lifecycle) into one canonical auth-failure entry; the no-guard and inert-logout observations are folded in as evidence because they share the same root cause (no auth state to enforce). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N/E:H/RL:U/RC:C.
Voucher redemption is "authenticated" by comparing the user-entered code to a string literal (ALISTY2K002) compiled into the client bundle. This is a shared secret embedded in shipped JavaScript: anyone who views source or DevTools (or guesses the short 11-char value) knows the valid code, and the success decision is made entirely in the browser with no server confirmation. The QR-scanner UI (vue-qrcode-reader) is wired to an undefined @detect handler and is therefore dead code, leaving the manual literal compare as the only working path. The associated redeemer identity USER-ALIST2023 is also hard-coded.
ScanVoucherView.vue), obtains ALISTY2K002, and types it into the voucher field. The length>=11 watcher fires checkVoucherCode(), the equality passes, and the UI shows "Voucher Redeemed! USER-ALIST2023" — with no server ever consulted. In a successor backed by a real ledger this becomes repeatable free redemption.The voucher code provides zero authentication value because it is a single static secret shipped to every client; every instance redeems the same code, and the "Voucher Redeemed!" result cannot be trusted. In this backend-less prototype nothing is actually fulfilled, but if this exact value or pattern were carried into a deployed/successor system it would enable unlimited free redemptions and value fraud. The literal also constitutes a secret-in-git, consistent with the engagement's secrets-in-repo priority.
ALISTY2K002 if it was ever used against any real backend.Merged the three scanner findings about ALISTY2K002 (client_secrets P2, auth_token P1, redemption) into one canonical entry; CVSS normalized to 6.5 — the value is a hard-coded shared secret (C:L) and the decision can be forged client-side (I:L), but in this repo there is no backend to defraud, so not the 7.5 some scanners assigned. CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N/E:H/RL:U/RC:C.
The app is a Vue 3 SPA (vue@3.4.23) but declares a DIRECT dependency on vue-file-upload@0.1.12, an abandoned package (last published ~2017) whose only dependency is Vue 2 (^2.4.2). The lockfile resolves this to the EOL vue@2.7.16 and @vue/compiler-sfc@2.7.16 nested under node_modules/vue-file-upload/, which npm itself marks deprecated. Vue 2 reached end-of-life on 2023-12-31 and receives no security patches; the Vue-2 SFC/template-compiler line carries the historical vue-template-compiler ReDoS / template-injection XSS class that will never be fixed. vue-file-upload is dead and unused, so it provides zero functionality while permanently pinning an EOL framework into the install/build surface and confusing SBOM/SCA tooling (two Vue majors for one app).
vue@^2.4.2 → 2.7.16, the project cannot patch by upgrade; any developer/CI that clones and npm installs runs the vulnerable, unpatchable compiler in its toolchain.Pure unmitigated supply-chain footprint with no offsetting benefit: any future CVE in the Vue 2 compiler/runtime line cannot be remediated by upgrade because the version is hard-pinned via an abandoned package. Exposure is build/install-time on developer and CI machines (the shipped artifact is the Vue 3 bundle, which does not include Vue 2), so availability/integrity impact is theoretical rather than a live production exposure — but it is trivially removable. Kept at P1 per the engagement's vulnerable-component weighting; real-world urgency is tempered by the repo being abandoned/superseded.
vue-file-upload from package.json (it is unused) and regenerate package-lock.json, which eliminates vue@2.7.16 and @vue/compiler-sfc@2.7.16 entirely. Add an SCA gate (npm audit / Snyk) that fails the build on EOL/deprecated packages, and run depcheck to find other phantom direct deps.Confirmed via lockfile parse: vue@2.7.16 and @vue/compiler-sfc@2.7.16 are present and nested under vue-file-upload, with the npm EOL deprecation flag set; the package is never imported in src/. CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H.
vite@5.2.9 is affected by the 2024-2025 dev-server file-read / server.fs.deny bypass family: CVE-2024-45811/45812 (XSS / fs.allow bypass) and the 2025 path-traversal set CVE-2025-30208 (the "?raw??" / "?import&raw??" trailing-separator bypass), CVE-2025-31125, CVE-2025-31486, CVE-2025-32395, and CVE-2025-46565, all permitting arbitrary file read outside the project root via the dev server. All are present in the 5.2.x branch and fixed in later 5.4.x / 6.x / 7.x releases. The repo's documented workflow runs npm run dev (vite). vite.config.js sets no custom server.host, so the dev server binds to localhost by default, limiting exposure to local/adjacent attackers and malicious websites probing the dev port; the impact is confidentiality-only (info disclosure of files reachable by the dev process).
npm run dev. While it is up, they visit a malicious page that issues crafted "?raw??" / trailing-separator requests to localhost:5173, bypassing server.fs.deny and reading arbitrary files (source, dotfiles, local secrets) reachable by the dev process, then exfiltrates them cross-origin.If a developer runs the Vite dev server, a malicious web page the developer visits (or anyone on the LAN if --host is ever passed) can read arbitrary files reachable by the dev process via crafted path-traversal requests, exfiltrating source and local secrets. This is a developer-workstation risk, not a production exposure (the shipped artifact is a static vite build). Because the build tooling is on the abandoned 5.2.x line, future Vite CVEs also go unpatched.
--host on untrusted networks. Since the project is superseded, at minimum document that npm run dev should not be used, and pin a patched Vite if the prototype must still build.Vite 5.2.9 version confirmed in lockfile; CVE list matches the known 2024-2025 dev-server advisory family. Dev-time/local exposure only — kept at P2/CVSS 5.3. CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N.
esbuild@0.20.2 is pulled in transitively by vite@5.2.9. esbuild versions <= 0.24.2 are affected by GHSA-67mh-4wv8-2f99: the esbuild dev/serve server sets Access-Control-Allow-Origin: * on all responses, so any website the developer visits can issue cross-origin requests to the local esbuild server and read the responses, including transpiled application source. Fixed in esbuild 0.25.0. The lockfile also marks esbuild hasInstallScript:true (a post-install step that places the platform binary), which npm ci/npm install executes automatically — the canonical install-time code-execution surface if the package were ever compromised upstream.
fetch() requests to the local esbuild server; because every response carries Access-Control-Allow-Origin: *, the attacker page reads back the transpiled source and exfiltrates it.On a developer workstation running the dev/serve tooling, a malicious page can exfiltrate the application's transpiled source via the permissive CORS policy. Confidentiality-only, local/adjacent, no production impact (built artifact is static). The install-script behavior is benign for the official package but is the standard vector exploited when a build dependency is trojanized upstream.
npm ci against a reviewed lockfile and consider npm config set ignore-scripts true for CI install steps that do not require install scripts (verify/pin binaries instead). Add SCA scanning to surface transitive advisories like this.esbuild 0.20.2 and hasInstallScript:true both confirmed in lockfile; advisory GHSA-67mh-4wv8-2f99 applies to <=0.24.2. Dev-time only — P2. CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N.
Five FilePond uploader instances configure label-idle with a raw HTML/SVG string, and FilePond renders labelIdle via innerHTML, making it an HTML sink by design. Verification confirms every label-idle in this repo is a hard-coded, developer-authored constant with NO interpolation of user, route, localStorage, API, or QR-scan data, and there is no v-html or other DOM-injection sink anywhere in src/. It is therefore NOT exploitable today. It is recorded as a latent/regression-only hardening concern: the same components set server="/api" (a currently dead upload endpoint), so a natural future evolution — wiring uploads and rendering a filename, error, or API-returned label through this attribute — would turn it into a stored/reflected XSS sink.
No impact in the current code (no untrusted data reaches the sink and there is no backend). The risk is purely a future-regression one: if a maintainer interpolates dynamic/server/user data into label-idle/labelIdle (or relies on FilePond rendering server error text), DOM/stored XSS could be introduced in an authenticated vendor context.
label-idle/labelIdle or other FilePond HTML-rendering options — keep them static or build from a fixed template; (2) if dynamic labels are required, sanitize with DOMPurify or pass plain text; (3) add a strict Content-Security-Policy (default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self') — currently absent from index.html — as defense-in-depth; (4) treat any future /api FilePond response strings as untrusted before display.Confirmed latent only — all five label-idle values are static literals (no dynamic binding), and there is no v-html/innerHTML/eval anywhere in src/. CVSS 0 / P3 is correct. CVSS vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:N.
A promotional/discount code is hard-coded as the default reactive value of promoCode and additionally left in an HTML comment, so it ships in the client bundle. In this prototype it only toggles a visual showDiscount flag (non-emptiness check) with no server validation, but it is a marketing/discount value exposed to every bundle reader and baked into git history.
ALIST2024RLONGPROMOCODE, and applies it in any successor system that reuses the value, obtaining an unauthorized discount.Low: discloses an internal promo code. If the same value were reused against a real discount engine in the successor it could let users apply an unauthorized discount. No effect in this backend-less prototype.
Confirmed at BillingView.vue:51 and :174. CVSS vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N.
Leftover debug console.log statements print the user-entered voucher code (itself the shared redemption secret) to the browser console on every change and on validation, and log the selected payment method. Console output is captured by browser extensions, screen recordings, and client-side error/telemetry tooling. 16 console.* calls remain across src/ and there is no build-time console-stripping configured.
Low: leaks the entered voucher value into client logs/telemetry, reinforcing the weak voucher control (AVP-02); also discloses routing/payment-method state. No PII beyond the voucher string is logged in this prototype.
drop:['console'] / vite-plugin-remove-console, or eslint no-console). Never log redemption codes, payment details, or any user input.Confirmed; 16 console.* across src/ verified by grep count. CVSS vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N.
The bank-transfer step renders A-List's (Metasphere Technologies / Emirates NBD) beneficiary account number, IBAN, SWIFT/BIC and Tax/VAT number as static template text rather than fetching them from config/API. These are the org's own receiving-account details intended to be shown to paying vendors, so they are semi-public by design, but committing them as source constants bakes real organizational financial identifiers permanently into the repo, git history, and the shipped bundle. A sample vendor email (emily@fujiyamasushi.com) is similarly hard-coded.
Minimal confidentiality impact since beneficiary details are disclosed to payers anyway; flagged for hygiene because real financial identifiers live permanently in git history and the bundle and could aid social-engineering / invoice-fraud (an attacker spoofing A-List's known banking details). The hard-coded sample email is low-grade PII / test-data hygiene.
user@example.com). Confirm these account/VAT numbers are the intended public payment details and not a different/internal account.Confirmed at BillingView.vue:408-414 and :195. Kept P3; this is hygiene/info-disclosure, not a direct exploit. CVSS vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N.
vite.config.js registers VueDevTools() unconditionally, with no command === 'serve' or mode === 'development' guard. While modern versions of vite-plugin-vue-devtools largely self-disable in build mode, relying on that implicit behavior is fragile; the intent of the config is to enable a component-inspection/debug surface, and an unguarded registration risks shipping devtools tooling (bundle bloat and an internal inspection surface) in any production bundle built from this repo.
Low: potential bundle bloat and a component-inspection surface exposed to anyone visiting a deployed build, and a leak of internal component structure for reconnaissance. No direct data compromise.
VueDevTools() only when command === 'serve' (via the function form of defineConfig), or remove it for production builds. Verify the produced dist/ does not include devtools assets.Folded in from the prior audit.html (not in the raw scanner set). Confirmed unguarded at vite.config.js:13. Kept P3 because current plugin versions may self-disable in build — the finding is a hardening/verify-the-bundle note. CVSS vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N.
package.json declares a DIRECT dependency on the npm package scss@0.2.4, an experimental OMeta-based SCSS parser last published ~2013, which pins ometa@0.2.2 (a 2013 PEG/OMeta library). Neither is imported anywhere in source — actual SCSS compilation is done by Dart sass@1.75.0. The scss package was almost certainly installed by name-confusion with sass. These are dead, decade-old packages occupying the dependency/install surface with no functional purpose; they still resolve cleanly with integrity hashes (no active tampering), so the risk is latent.
^0.2.4 / 0.2.2 range, and any developer/CI that reinstalls the prototype executes the trojanized code at install time.Latent supply-chain footprint: abandoned packages can be hijacked (maintainer-account takeover / expired-domain email reclaim) and weaponized, and their decade-old code runs at install time on developer/CI machines. They also pollute SBOM/SCA output and signal poor dependency hygiene. No exploitable behavior in the running app (never imported).
scss from package.json (it is unused; Dart sass already handles all .scss files) and regenerate the lockfile, which also drops ometa. Run depcheck to audit declared dependencies against actual imports and remove other phantom packages (e.g. AVP-03's vue-file-upload).Both packages confirmed present in lockfile and absent from src/ imports. Latent — P3. CVSS vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N.
braces@3.0.2 is present transitively (micromatch/chokidar → file watching used by Vite/Vitest) and is affected by CVE-2024-4068 (uncontrolled resource consumption / ReDoS-style memory exhaustion on crafted brace patterns), fixed in 3.0.3. nanoid@3.3.7 is present transitively and is affected by CVE-2024-55565 (predictable/non-uniform output when called with a non-integer length), fixed in 3.3.8. Both are exercised only by build/test tooling in this frontend-only prototype, not in any request-handling path, and never process attacker-controlled input in the shipped static bundle, so real-world exploitability here is minimal.
Low. Build-time/test-time dependencies in a static-SPA prototype with no server. braces ReDoS could in theory slow a build given a hostile glob; nanoid's weakness matters only if used to mint security tokens with attacker-influenced length (not done here). Primary value is hygiene and preventing these advisories from propagating to tooling that copies this dependency set.
npm audit fix / refresh the lockfile so braces >= 3.0.3 and nanoid >= 3.3.8 resolve. Typically auto-resolved by regenerating the lockfile against current registry metadata; no API changes required.braces 3.0.2 and nanoid 3.3.7 confirmed in lockfile. Build-time only — P3. CVSS vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L.
There is no CI/CD configuration anywhere in the repo or its history, and no automated dependency scanning, lockfile-integrity, or SCA quality gate. On the positive side this means no pipeline secrets, no force-push-to-mirror steps, no unpinned third-party actions, and no expression-injection risk to flag. The downside is that the EOL/vulnerable components (AVP-03/04/05/11/12) would never be surfaced by a gate, and installs run unpinned install scripts (esbuild hasInstallScript) on whatever Node version a developer happens to have.
No active CI attack surface (good), but the absence of any SCA gate means vulnerable/EOL components accumulate undetected. The repo is abandoned (last commit 2024-05-15) and superseded by alist-vendors, so operational risk is contained to anyone who still clones/builds the prototype.
npm audit --audit-level=high or Snyk), use npm ci against the reviewed lockfile with --ignore-scripts where feasible, pin engines.node, and SHA-pin any actions if a pipeline is ever added.Confirmed: no CI config in tree; package.json has no engines pin and no .npmrc. Hygiene — P3. CVSS vector: CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:N.
alist-vendors (AVP-13).ALISTY2K002 if it was ever used against a real backend, and correlate the value across sibling repos (AVP-02).vue-file-upload from package.json and regenerate the lockfile to eliminate EOL vue@2.7.16 / @vue/compiler-sfc@2.7.16 (AVP-03).scss dependency (drops ometa); run depcheck for other phantom direct deps (AVP-11).npm audit fix / refresh lockfile so braces >= 3.0.3 and nanoid >= 3.3.8 resolve (AVP-12).console.* debug statements (AVP-08).--host on untrusted networks (AVP-04).VueDevTools() behind command === 'serve' and verify dist/ excludes devtools assets (AVP-10).npm audit --audit-level=high / Snyk), pin engines.node, and use npm ci --ignore-scripts where feasible (AVP-13).alist-vendors.
HttpOnly+Secure+SameSite cookie, a global router guard checking a server-validated session, meta.requiresAuth on protected routes; never trust a client "Admin" label (AVP-01).label-idle; sanitize with DOMPurify if dynamic labels are required (AVP-06).default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self') — absent from index.html today (AVP-06).views/BillingView.vue — 764 lines, four-step wizard, all in one file. RedemptionsView.vue (399L) and TeamManagementView.vue (388L) are next.components/TheWelcome.vue, components/WelcomeItem.vue, components/HelloWorld.vue (referenced only by the template test). src/icons/index.vue appears unused vs components/icons/*. The QR @detect handler in ScanVoucherView.vue is undefined (dead QR path).CampaignPosts.vue:195-196; 16 console.log calls shipping in production (AVP-08); "DONE :" prefix on nearly every commit message.git clone <bitbucket-url>
cd alist-vendor-portal
npm install
npm run dev # vite dev server, default http://localhost:5173 — see AVP-04/AVP-05
npm run build # static bundle into dist/
npm run preview # serve the built dist/
npm run test:unit # vitest (one trivial spec)
npm run lint # eslint --fix
engines pin and no .npmrc, so install scripts run on whatever Node is present (AVP-13)..env or .env.example committed, and no import.meta.env.VITE_* usage in source.npm run dev with --host on untrusted networks — Vite 5.2.9 / esbuild 0.20.2 carry dev-server file-read / CORS advisories (AVP-04/AVP-05).No Dockerfile, no bitbucket-pipelines.yml, no Vercel/Netlify config, no IaC in the repo. Most likely deployed (if at all) as a static vite build output to a CDN bucket configured outside this codebase. Confirm with the team where (and whether) this was ever published before spending time on hosting — a publicly reachable build means every "protected" screen is anonymously accessible (AVP-01).
alist-vendors (Next.js, commits through Nov 2025). Default answer to "should I change this?" is no — change alist-vendors instead./api endpoint and do not upload. Stakeholders may not realize this from a demo.BillingView.vue ships a non-empty hard-coded promo code (ALIST2024RLONGPROMOCODE, AVP-07) and real beneficiary banking details (IBAN/SWIFT/VAT, AVP-09). Do not treat these as configuration, and confirm the bank details are intentionally public.vue-file-upload drags EOL Vue 2.7.16 into the install tree (AVP-03); phantom scss/ometa packages are declared but never imported (AVP-11). Remove both before any reuse.VueDevTools() is unconditionally enabled in vite.config.js — verify it does not end up in any production bundle built from this repo (AVP-10).App.vue uses both Composition and Options API in the same file. The noSideBar computed is misleadingly named (it's true when the sidebar should show).public/fonts/. The Next.js successor should ship only the woff2 files it actually uses.package.json is alistbussinessdashboard (sic) — useful when grepping commit history / build artifacts.HelloWorld.spec.js; treat coverage as zero. There is no CI/CD and no SCA gate (AVP-13).git@bitbucket.org:ParhamandCo/alist-vendor-portal.git — correlate Bitbucket access/app-password posture across the org's repos as part of the wider engagement.