Security audit
Security checks for vulnerabilities and agentic risk
The skill is a legitimate browser-automation helper, but it is broad enough to let an agent submit forms, post content, reuse login sessions, and access browser cookies without strong confirmation boundaries.
Install only if you want an agent to help control websites through Actionbook. Require explicit approval before it submits forms, sends messages, posts content, books, buys, changes account settings, or extracts authenticated data. Use dedicated low-privilege accounts and browser profiles, protect API keys and session tokens, avoid connecting your everyday browser session unless necessary, and clear cookies or delete profiles after sensitive work.
The skill’s activation criteria are extremely broad, effectively covering almost any request involving a website. That creates a routing and authority problem: the skill may be invoked for sensitive, high-risk, or irreversible web actions without narrower scoping, increasing the chance of unintended automation on third-party sites.
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 enables browser automation for external websites, including form filling, content posting, and repetitive task automation, but it does not warn about data submission, side effects, or irreversible operations. In practice, this can lead to accidental posting, purchases, submissions, or disclosure of sensitive data if the agent proceeds without explicit user confirmation.
The profile persistence pattern intentionally stores authenticated browser state across invocations, which increases the attack surface by keeping reusable session cookies and storage on disk. In a browser automation skill this behavior is expected and useful, but it is still security-relevant because compromised local access, shared machines, or poorly protected profile directories can enable session hijacking without reauthentication.
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
The cookie-based auth example shows how to inject a live session token into the browser as an authentication cookie, which effectively impersonates an already authenticated user. In an automation skill focused on website interaction, this is functional but security-sensitive; without an explicit warning, users may normalize unsafe handling of bearer/session tokens and accidentally expose them via shell history, logs, shared environments, or reuse across targets.
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 section documents listing, retrieving, setting, deleting, and clearing browser cookies, which can expose authentication state or disrupt active sessions. The reference provides command syntax only and does not include any warning about handling sensitive session data or the effect of deleting or clearing cookies.
The file documents api.api_key and ACTIONBOOK_API_KEY as normal configuration values but does not warn that they are secrets that should be protected from logs, screenshots, shell history, or source control. For markdown files, omission of warnings around credential-related behavior is a quality and safety issue because it can affect user privacy and account security.
The practical examples demonstrate filling forms, submitting passwords, extracting page data, connecting to an existing browser session, and taking screenshots, all of which can affect user data, privacy, or authenticated sessions. The markdown does not provide any caution about using test environments, avoiding real credentials, or confirming authorization to access and extract site data.
No suspicious patterns detected.