Security audit
Security checks for vulnerabilities and agentic risk
This browser automation skill is coherent, but it needs review because it can act on logged-in websites, persist sessions, and includes unsafe credential-loading guidance.
Install only if you intentionally want agents to control browsers and interact with live websites. Use separate profiles for each site, treat profile directories and cookies like passwords, delete them when done, and require explicit confirmation before purchases, account changes, messages, posts, or other state-changing actions. Do not run `source .env` from an untrusted project; use credentials already exported by a trusted shell setup or a secrets manager.
references/authentication.md:140Unsafe Shell Execution Through Sourced Environment File
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
.env file, not inline
# Load from .env file (avoid typing secrets in the terminal)
source .env # contains APP_USERNAME, APP_PASSWORD
actionbook browser fill "#email" "$APP_USERNAME"
actionbook browser fill "#password" "$APP_PASSWORD"
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
.env file, not inline
# Load from .env file (avoid typing secrets in the terminal)
source .env # contains APP_USERNAME, APP_PASSWORD
actionbook browser fill "#email" "$APP_USERNAME"
actionbook browser fill "#password" "$APP_PASSWORD"
The skill declares activation for essentially any request involving a website, which is far broader than a narrowly scoped capability trigger. Overbroad activation can cause the agent to invoke browser automation in ordinary informational requests, increasing the chance of unnecessary tool use, unintended navigation, form interaction, or exposure to prompt-injection content from external sites.
The invocation guidance repeatedly says to activate for 'anything on a website' and includes broad examples like asking how to interact with a site, which blurs the line between advice and action. In a browser-automation skill, this is more dangerous because triggering on vague website-related requests can push the agent into high-risk workflows involving external content, authenticated sessions, and live state-changing actions.
The documentation explicitly encourages persistent browser profiles that preserve cookies and authenticated session state across invocations. While useful for automation, persisted sessions are sensitive artifacts equivalent to bearer credentials; if the profile directory is accessed by another local user, malware, or an overly permissive backup/sync process, an attacker may hijack authenticated sessions without knowing the password or 2FA secret.
Profiles provide isolated browser sessions with separate cookies and storage. Use profiles to persist authentication across CLI invocations.
# Create a dedicated profile for the target site
actionbook profile create myapp
# Login using that profile
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
Protect profile directories — profiles store cookies and session data on disk
# Profile data is equivalent to passwords — restrict access
chmod 700 ~/.config/actionbook/
Clean up sessions after automation
This markdown file documents cookies set, cookies delete, and cookies clear, which can alter authentication state and remove browser data, but it provides no user warning about the impact on sessions or persisted state. Under the markdown-specific SQP-2 criteria, behaviors that can affect user data or system integrity should be accompanied by warnings.
The documentation instructs users to use api.api_key and ACTIONBOOK_API_KEY but does not warn that these values are sensitive secrets that should not be shared, committed, or logged. For markdown files, omission of privacy- or integrity-related warnings around credential handling qualifies as a missing user warning.