Back to skill

Security audit

ia-react-frontend

Security checks for vulnerabilities and agentic risk

Overview

The skill is mostly coherent React guidance, but its E2E testing instructions can lead users to save reusable login state and credentials without enough safeguards.

Review before installing if your projects use real test accounts or CI secrets. Treat Playwright storage-state files as secrets, keep e2e/.auth/ out of version control and artifacts, use environment or CI secret stores instead of source-coded passwords, and use dedicated low-privilege test accounts.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (2)

T09 · Insecure Skill Coding Practices

Warning
Location
references/e2e-testing.md:136
Finding
Unprotected Authentication State and Hardcoded Test Credential Pattern## Vulnerability Details **File Location**: `references/e2e-testing.md:48` and `references/e2e-testing.md:136-147` **Vulnerability Type**: Plaintext sensitive data and unsafe authentication artifact handling **Risk Level**: Medium ### Vulnerable Code ```typescript { name: 'chromium', use: { ...devices['Desktop Chrome'], storageState: 'e2e/.auth/user.json' }, dependencies: ['setup'], }, ``` ```typescript // e2e/fixtures/auth.fixture.ts import { test as setup } from '@playwright/test'; setup('authenticate', async ({ page }) => { await page.goto('/login'); await page.getByLabel('Email').fill('testuser@example.com'); await page.getByLabel('Password').fill('TestPassword123!'); await page.getByRole('button', { name: /sign in/i }).click(); await page.waitForURL('/dashboard'); await page.context().storageState({ path: 'e2e/.auth/user.json' }); }); ``` Tests receive auth state via `storageState` in config projects. ### Technical Analysis The guidance demonstrates embedding a password directly in test source and persisting Playwright authentication state under the repository directory. A Playwright storage-state file can contain reusable cookies, bearer tokens, local-storage entries, and other session material. The document does not require the `e2e/.auth/` directory to be excluded from version control, restrict file permissions, remove generated state after execution, or prevent the file from being published as a CI artifact. Although the shown password appears to be an example credential rather than a verified production secret, following this pattern with real test credentials or sessions can expose authentication material. ### Attack Path 1. A developer follows the documented fixture and substitutes credentials for a functioning test account. 2. Playwright authenticates and writes session cookies or tokens to `e2e/.auth/user.json`. 3. The generated file is accidentally committed, ...[truncated 829 chars]
Remediation
## Remediation Suggestions - Require `e2e/.auth/` and all generated storage-state files to be listed in `.gitignore`. - Obtain test credentials from an approved environment-variable or CI secret store rather than embedding them in source. - Use a dedicated, isolated, least-privilege test account with short-lived credentials. - Create authentication-state files with restrictive owner-only permissions where supported. - Delete storage-state files in test teardown and prevent them from being included in logs, caches, screenshots, traces, and uploaded artifacts. - Prefer short-lived sessions and revoke test sessions after the test run. - Add secret scanning and repository checks that reject committed storage-state files or hardcoded credentials.

T08 · Insecure Dependencies

Note
Location
references/testing.md:86
Finding
Unrestricted npx Commands Can Retrieve and Execute Unreviewed Packages## Vulnerability Details **File Location**: `references/testing.md:86-91` and `references/e2e-testing.md:164-180` **Vulnerability Type**: Unsafe third-party package resolution and execution **Risk Level**: Low ### Vulnerable Code ```bash npx vitest # Watch mode npx vitest run # Single run (CI) npx vitest run src/features/ # Test specific directory npx vitest --coverage # Coverage report ``` ```bash npx playwright test --repeat-each=10 path/to/test.spec.ts # Confirm flakiness npx playwright test --retries=3 path/to/test.spec.ts # Check if retries help ``` ```bash npx playwright test --headed --debug # Debug mode npx playwright show-trace trace.zip # Trace viewer npx playwright test --ui # Interactive UI ``` ### Technical Analysis The Skill recommends executing `npx` commands without requiring that the corresponding package already be installed from a reviewed lockfile. Depending on the npm and `npx` version and configuration, a missing local executable may cause package content to be resolved and downloaded from the configured registry. Package binaries and installation lifecycle scripts execute with the privileges of the developer or CI account. Consequently, a compromised registry, malicious registry configuration, package-name confusion, or an absent local dependency could turn an ordinary test command into execution of unreviewed third-party code. ### Attack Path 1. The expected local `vitest` or `playwright` executable is absent, incorrectly installed, or unavailable in the active workspace. 2. A developer or CI job runs one of the documented `npx` commands. 3. `npx` resolves the package through the configured npm registry instead of a verified local installation. 4. A malicious or compromised package version is downloaded. 5. Its executable or lifecycle script runs with the privileges and environment access o ...[truncated 522 chars]
Remediation
## Remediation Suggestions - Install dependencies from a reviewed, committed lockfile using an immutable command such as `npm ci`. - Invoke only project-local binaries, for example through package scripts or `./node_modules/.bin/vitest`. - If `npx` remains necessary, require local-only or offline resolution and fail when the executable is not already installed. - Pin and review dependency versions rather than resolving an unspecified current registry version. - Use a trusted registry with integrity verification and restrict registry overrides in developer and CI environments. - Disable unnecessary lifecycle scripts where compatible with the project and run dependency installation with least-privilege CI credentials.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (1)

Missing User Warnings

Medium
Confidence
88% confidence
Finding
The document instructs users to persist authenticated browser state to a file (`e2e/.auth/user.json`) without warning that this file may contain reusable session cookies or tokens. If that file is committed, shared, or read by other local processes, an attacker could reuse the session to access the application as the test user.

Static analysis

No suspicious patterns detected.