T09 · Insecure Skill Coding Practices
- Location
references/api-endpoints.md:3- Finding
Unauthenticated High-Impact WhatsApp Control API Recommended for Production Use
- Content
View full analysis
Vulnerability Details
File Location:
references/api-endpoints.md:3-8andSKILL.md:28-38
Vulnerability Type: Unauthenticated access to a sensitive local control API
Risk Level: MediumVulnerable code segment (
references/api-endpoints.md:3-8):markdown Base URL: `http://localhost:3000` (default) ## Authentication - No authentication required by default - Optional Basic Auth (if GOWA started with `--basic-auth=user:password`) - Header: `Authorization: Basic <base64(user:password)>`Related production guidance (
SKILL.md:28-38):markdown ## Production Setup **GOWA runs in REST mode:** - Base URL: `http://localhost:3000` - GOWA auto-connects to the device stored in the database — no `X-Device-Id` header needed for single-device setups. **⚠️ Important:** Use REST API (port 3000) only. Do NOT use MCP mode - all schedulers and automation depend on REST.Technical Analysis
The Skill recommends using the REST service in production while documenting that authentication is disabled by default. The service controls a linked WhatsApp account and exposes sensitive and destructive operations, including reading chats and contacts, downloading message media, sending messages, changing group membership and administrator roles, logging out devices, and obtaining login information.
Binding the service to
localhostcan reduce direct network exposure, but it is not an authentication boundary. Other local processes may access the API, and applications vulnerable to server-side request forgery may be able to send requests to loopback services. Exposure may also increase if the service is inadvertently bound to a non-loopback interface, published from a container, or made reachable through a reverse proxy.Because Basic Authentication is merely optional, following the documented default configuration can leave all API capabilities available without proving the caller's identit ...[truncated 1841 chars]
- Remediation
View remediation
Remediation Suggestions
- Require authentication in all documented production configurations rather than presenting it as optional.
- Generate a strong, unique credential for the service and store it in a protected secret store or environment variable rather than source files or shell history.
- Bind the service explicitly to the loopback interface when remote access is unnecessary; do not rely only on a port number or hostname convention.
- Apply host firewall rules so that only authorized local users or trusted management systems can reach port 3000.
- If remote access is required, place the service behind an authenticated TLS reverse proxy, restrict source networks, and avoid directly publishing the API port.
- Isolate the service in a dedicated operating-system account or container with narrowly scoped network access and protected session data.
- Add authorization controls for high-impact operations, particularly device logout, media download, message sending, and group administration.
- Apply request rate limits, audit logging, and alerts for unusual message volume, mass mentions, account changes, or group administration activity.
- Validate
Originand other relevant request context where browser access is supported, and use appropriate anti-CSRF protections for state-changing browser requests. - Update the Skill documentation so every production example includes authenticated requests and clearly warns that unauthenticated mode is suitable only for tightly isolated development environments.