I have a comprehensive view of the security issues. Now let me create the security hardening ideas JSON file. Here are the key findings:

1. **Authentication bypass** - The auth module doesn't actually validate JWT or API keys
2. **Overly permissive CORS** - `allow_origin(Any)` is dangerous
3. **Hardcoded dev-key** - Default API key is insecure
4. **WebSocket endpoints unprotected** - No auth on /ws/agent and /ws/viewer
5. **No rate limiting** - DoS vulnerability

Let me write the security hardening file.


Now I have a complete picture of the security vulnerabilities. Let me write the security hardening ideas file:


Write

{
  "security_hardening": [
    {
      "id": "sec-001",
      "type": "security_hardening",
      "title": "Implement JWT and API Key Authentication (Currently Bypassed)",
      "description": "The authentication module in server/src/auth/mod.rs contains placeholder code that accepts any request without validation. The `from_request_parts()` function returns hardcoded credentials ('mvp-user', 'admin' role) regardless of the Authorization header, and `validate_agent_key()` accepts any API key. This means anyone can access all endpoints and any agent can connect to the server without valid credentials.",
      "rationale": "This is a remote desktop control application - unauthenticated access allows attackers to view and control any connected machine. The current code essentially disables all security, making the entire system completely exposed to unauthorized access.",
      "category": "authentication",
      "severity": "critical",
      "affectedFiles": [
        "server/src/auth/mod.rs",
        "server/src/config.rs",
        "server/src/relay/mod.rs"
      ],
      "vulnerability": "CWE-306: Missing Authentication for Critical Function",
      "currentRisk": "Any attacker can access the server, view active sessions, connect as an agent, and view/control remote desktops without any credentials",
      "remediation": "1. Implement proper JWT validation in `from_request_parts()` using the jsonwebtoken crate (already in dependencies). 2. Validate JWT signature against JWT_SECRET config. 3. Check token expiration and claims. 4. Implement proper API key validation in `validate_agent_key()` by verifying keys against the database. 5. Require JWT_SECRET to be set in production (fail startup if missing).",
      "references": [
        "https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/",
        "https://cwe.mitre.org/data/definitions/306.html"
      ],
      "compliance": ["SOC2", "HIPAA", "PCI-DSS"]
    },
    {
      "id": "sec-002",
      "type": "security_hardening",
      "title": "Add Authentication to WebSocket Endpoints",
      "description": "The WebSocket endpoints `/ws/agent` and `/ws/viewer` in server/src/relay/mod.rs have no authentication. Anyone can connect as an agent (sending arbitrary screen content) or as a viewer (receiving screen frames and sending input). The agent_ws_handler accepts any agent_id without validation, and viewer_ws_handler allows joining any session without permission checks.",
      "rationale": "WebSocket endpoints provide the core functionality of remote desktop access. Without authentication, attackers can: 1) Register fake agents to phish users, 2) Connect to any active session to view screens, 3) Send input to control remote machines. This completely bypasses intended access controls.",
      "category": "authorization",
      "severity": "critical",
      "affectedFiles": [
        "server/src/relay/mod.rs",
        "server/src/session/mod.rs",
        "agent/src/transport/websocket.rs"
      ],
      "vulnerability": "CWE-862: Missing Authorization",
      "currentRisk": "Attackers can connect to any session and view/control remote desktops without authorization. Fake agents can be registered to impersonate legitimate machines.",
      "remediation": "1. Require API key in WebSocket upgrade request for agents (passed in query string, already there as api_key but not validated). 2. Validate JWT token for viewer connections via Authorization header or query parameter. 3. Implement session-level authorization to verify viewer has permission to access the specific agent/organization. 4. Add connection rate limiting to prevent enumeration attacks.",
      "references": [
        "https://owasp.org/www-community/attacks/WebSocket_attacks",
        "https://cwe.mitre.org/data/definitions/862.html"
      ],
      "compliance": ["SOC2", "PCI-DSS"]
    },
    {
      "id": "sec-003",
      "type": "security_hardening",
      "title": "Restrict Overly Permissive CORS Configuration",
      "description": "In server/src/main.rs, CORS is configured with `CorsLayer::new().allow_origin(Any).allow_methods(Any).allow_headers(Any)`. This allows any website on the internet to make authenticated requests to the GuruConnect API, potentially enabling CSRF attacks and unauthorized access from malicious sites.",
      "rationale": "With wildcard CORS, a malicious website could use JavaScript to make requests to the GuruConnect server using the victim's stored credentials. This could allow attackers to enumerate sessions, steal data, or initiate remote desktop connections from the victim's browser.",
      "category": "configuration",
      "severity": "high",
      "affectedFiles": [
        "server/src/main.rs",
        "server/src/config.rs"
      ],
      "vulnerability": "CWE-942: Overly Permissive Cross-domain Whitelist",
      "currentRisk": "Any website can make API requests to the server. Combined with stored authentication tokens, this enables cross-site request forgery attacks.",
      "remediation": "1. Configure allowed origins explicitly based on deployment environment. 2. Add ALLOWED_ORIGINS config variable for production domains. 3. Restrict to localhost origins in development. 4. Only allow necessary HTTP methods (GET, POST, DELETE). 5. Specify allowed headers explicitly. Example: `CorsLayer::new().allow_origin([\"https://dashboard.example.com\".parse().unwrap()])`",
      "references": [
        "https://owasp.org/www-community/attacks/csrf",
        "https://cwe.mitre.org/data/definitions/942.html"
      ],
      "compliance": ["SOC2"]
    },
    {
      "id": "sec-004",
      "type": "security_hardening",
      "title": "Remove Hardcoded Default API Key and Require Secure Configuration",
      "description": "In agent/src/config.rs line 115, the default API key is hardcoded as 'dev-key': `.unwrap_or_else(|_| \"dev-key\".to_string())`. If deployed without explicit configuration, all agents will use this predictable key, allowing attackers to connect unauthorized agents to the server.",
      "rationale": "Hardcoded credentials are a common vulnerability that leads to unauthorized access. In a remote desktop tool, this could allow attackers to register malicious agents, potentially enabling supply chain attacks or unauthorized surveillance.",
      "category": "secrets_management",
      "severity": "high",
      "affectedFiles": [
        "agent/src/config.rs",
        "server/src/config.rs"
      ],
      "vulnerability": "CWE-798: Use of Hard-coded Credentials",
      "currentRisk": "Agents deployed without explicit API key configuration will use the same predictable 'dev-key', allowing unauthorized agent connections",
      "remediation": "1. Remove default API key - require explicit configuration. 2. Fail agent startup if GURUCONNECT_API_KEY is not set. 3. Add configuration validation on startup. 4. Require JWT_SECRET on server in production mode. 5. Add a --generate-key CLI command to create secure random API keys. 6. Document secure deployment practices.",
      "references": [
        "https://owasp.org/www-community/vulnerabilities/Use_of_hard-coded_password",
        "https://cwe.mitre.org/data/definitions/798.html"
      ],
      "compliance": ["SOC2", "PCI-DSS"]
    },
    {
      "id": "sec-005",
      "type": "security_hardening",
      "title": "Add Rate Limiting and Connection Throttling",
      "description": "The server has no rate limiting on any endpoints including the REST API, WebSocket connections, and session management. An attacker could: 1) Brute force session IDs to access active sessions, 2) Flood the server with connection attempts causing DoS, 3) Enumerate active agents and sessions, 4) Exhaust server resources with many concurrent WebSocket connections.",
      "rationale": "Rate limiting is essential for protecting against enumeration attacks, denial of service, and brute force attempts. Given that this is a security-sensitive remote access tool, lack of rate limiting significantly increases attack surface.",
      "category": "configuration",
      "severity": "medium",
      "affectedFiles": [
        "server/src/main.rs",
        "server/src/relay/mod.rs",
        "server/src/api/mod.rs"
      ],
      "vulnerability": "CWE-770: Allocation of Resources Without Limits",
      "currentRisk": "Server vulnerable to DoS attacks, session enumeration, and brute force attacks on session IDs",
      "remediation": "1. Add tower-governor or similar rate limiting middleware to Axum router. 2. Implement per-IP connection limits for WebSocket endpoints. 3. Add exponential backoff for failed authentication attempts. 4. Limit concurrent sessions per agent. 5. Implement request throttling on API endpoints. Example: `RateLimitLayer::new(100, Duration::from_secs(60))` for 100 requests/minute.",
      "references": [
        "https://owasp.org/www-community/controls/Blocking_Brute_Force_Attacks",
        "https://cwe.mitre.org/data/definitions/770.html"
      ],
      "compliance": ["SOC2"]
    }
  ],
  "metadata": {
    "dependenciesScanned": 42,
    "knownVulnerabilities": 0,
    "filesAnalyzed": 25,
    "criticalIssues": 2,
    "highIssues": 2,
    "mediumIssues": 1,
    "lowIssues": 0,
    "generatedAt": "2026-01-11T15:35:00Z",
    "scanNotes": "cargo audit not installed - dependency CVE scan skipped. Recommend running 'cargo install cargo-audit && cargo audit' to check for known vulnerabilities in Rust dependencies."
  }
}


File created successfully at: C:\Users\MikeSwanson\claude-projects\guru-connect\.auto-claude\ideation\security_hardening_ideas.json

Implement JWT and API Key Authentication (Currently Bypassed)

The authentication module in server/src/auth/mod.rs contains placeholder code that accepts any request without validation. The `from_request_parts()` function returns hardcoded credentials ('mvp-user', 'admin' role) regardless of the Authorization header, and `validate_agent_key()` accepts any API key. This means anyone can access all endpoints and any agent can connect to the server without valid credentials.

Explanation: This is a remote desktop control application - unauthenticated access allows attackers to view and control any connected machine. The current code essentially disables all security, making the entire system completely exposed to unauthorized access.

CWE-306: Missing Authentication for Critical Function

Any attacker can access the server, view active sessions, connect as an agent, and view/control remote desktops without any credentials

1. Implement proper JWT validation in `from_request_parts()` using the jsonwebtoken crate (already in dependencies). 2. Validate JWT signature against JWT_SECRET config. 3. Check token expiration and claims. 4. Implement proper API key validation in `validate_agent_key()` by verifying keys against the database. 5. Require JWT_SECRET to be set in production (fail startup if missing).

Add Authentication to WebSocket Endpoints

The WebSocket endpoints `/ws/agent` and `/ws/viewer` in server/src/relay/mod.rs have no authentication. Anyone can connect as an agent (sending arbitrary screen content) or as a viewer (receiving screen frames and sending input). The agent_ws_handler accepts any agent_id without validation, and viewer_ws_handler allows joining any session without permission checks.

Explanation: WebSocket endpoints provide the core functionality of remote desktop access. Without authentication, attackers can: 1) Register fake agents to phish users, 2) Connect to any active session to view screens, 3) Send input to control remote machines. This completely bypasses intended access controls.

Attackers can connect to any session and view/control remote desktops without authorization. Fake agents can be registered to impersonate legitimate machines.

1. Require API key in WebSocket upgrade request for agents (passed in query string, already there as api_key but not validated). 2. Validate JWT token for viewer connections via Authorization header or query parameter. 3. Implement session-level authorization to verify viewer has permission to access the specific agent/organization. 4. Add connection rate limiting to prevent enumeration attacks.

Restrict Overly Permissive CORS Configuration

In server/src/main.rs, CORS is configured with `CorsLayer::new().allow_origin(Any).allow_methods(Any).allow_headers(Any)`. This allows any website on the internet to make authenticated requests to the GuruConnect API, potentially enabling CSRF attacks and unauthorized access from malicious sites.

Explanation: With wildcard CORS, a malicious website could use JavaScript to make requests to the GuruConnect server using the victim's stored credentials. This could allow attackers to enumerate sessions, steal data, or initiate remote desktop connections from the victim's browser.

CWE-942: Overly Permissive Cross-domain Whitelist

Any website can make API requests to the server. Combined with stored authentication tokens, this enables cross-site request forgery attacks.

1. Configure allowed origins explicitly based on deployment environment. 2. Add ALLOWED_ORIGINS config variable for production domains. 3. Restrict to localhost origins in development. 4. Only allow necessary HTTP methods (GET, POST, DELETE). 5. Specify allowed headers explicitly. Example: `CorsLayer::new().allow_origin(["https://dashboard.example.com".parse().unwrap()])`

Remove Hardcoded Default API Key and Require Secure Configuration

In agent/src/config.rs line 115, the default API key is hardcoded as 'dev-key': `.unwrap_or_else(|_| "dev-key".to_string())`. If deployed without explicit configuration, all agents will use this predictable key, allowing attackers to connect unauthorized agents to the server.

Explanation: Hardcoded credentials are a common vulnerability that leads to unauthorized access. In a remote desktop tool, this could allow attackers to register malicious agents, potentially enabling supply chain attacks or unauthorized surveillance.

Agents deployed without explicit API key configuration will use the same predictable 'dev-key', allowing unauthorized agent connections

1. Remove default API key - require explicit configuration. 2. Fail agent startup if GURUCONNECT_API_KEY is not set. 3. Add configuration validation on startup. 4. Require JWT_SECRET on server in production mode. 5. Add a --generate-key CLI command to create secure random API keys. 6. Document secure deployment practices.

Add Rate Limiting and Connection Throttling

The server has no rate limiting on any endpoints including the REST API, WebSocket connections, and session management. An attacker could: 1) Brute force session IDs to access active sessions, 2) Flood the server with connection attempts causing DoS, 3) Enumerate active agents and sessions, 4) Exhaust server resources with many concurrent WebSocket connections.

Explanation: Rate limiting is essential for protecting against enumeration attacks, denial of service, and brute force attempts. Given that this is a security-sensitive remote access tool, lack of rate limiting significantly increases attack surface.

CWE-770: Allocation of Resources Without Limits

Server vulnerable to DoS attacks, session enumeration, and brute force attacks on session IDs

1. Add tower-governor or similar rate limiting middleware to Axum router. 2. Implement per-IP connection limits for WebSocket endpoints. 3. Add exponential backoff for failed authentication attempts. 4. Limit concurrent sessions per agent. 5. Implement request throttling on API endpoints. Example: `RateLimitLayer::new(100, Duration::from_secs(60))` for 100 requests/minute.

cargo audit not installed - dependency CVE scan skipped. Recommend running 'cargo install cargo-audit && cargo audit' to check for known vulnerabilities in Rust dependencies.


I've completed the security hardening analysis and created the output file. Let me summarize what I found for the user.


I've completed the security analysis of the GuruConnect codebase. Here's a summary of the findings:

## Security Hardening Analysis Complete

### Critical Issues Found (2)

1. **Authentication Bypass (sec-001)**: The `auth/mod.rs` module has TODO placeholders that accept any request without validating JWT tokens or API keys. The code returns hardcoded "mvp-user" with "admin" role for all requests.

2. **Unprotected WebSocket Endpoints (sec-002)**: The `/ws/agent` and `/ws/viewer` endpoints have no authentication. Anyone can connect as an agent or join any session to view/control remote desktops.

### High Severity Issues (2)

3. **Overly Permissive CORS (sec-003)**: The server uses `allow_origin(Any)` which allows any website to make authenticated requests, enabling CSRF attacks.

4. **Hardcoded Default API Key (sec-004)**: The agent uses `"dev-key"` as default, meaning unonfigured deployments share predictable credentials.

### Medium Severity Issues (1)

5. **No Rate Limiting (sec-005)**: No protection against DoS, brute force attacks, or session enumeration.

### Additional Notes
- `cargo audit` is not installed, so CVE scanning of Rust dependencies was skipped
- Recommend installing and running `cargo audit` to check for known vulnerabilities

The output has been written to:
`C:\Users\MikeSwanson\claude-projects\guru-connect\.auto-claude\ideation\security_hardening_ideas.json`