The core-developer package provides powerful administrative capabilities that require careful security controls. This document outlines the security model, known risks, and mitigation strategies.

1. Application logs - May contain tokens, passwords, PII in error messages
2. Database access - Read-only query execution against production data
3. SSH keys - Encrypted private keys for server connections
4. Cache data - Application cache, session data, config cache
5. Route information - Full application route structure

1. Unauthorized users - Non-Hades users attempting to access dev tools
2. Compromised Hades account - Attacker with valid Hades credentials
3. SSRF/Injection - Attacker manipulating dev tools to access internal resources
4. Data exfiltration - Extracting sensitive data via dev tools

All developer tools require "Hades" access, verified via the isHades() method on the User model. This is enforced at multiple layers:

The authorization is intentionally redundant:

• API routes use RequireHades middleware
• Livewire components check in mount()
• Some controller methods call $this->authorize()

This ensures access is blocked even if one layer fails.

Tests currently pass without setting Hades tier on the test user. This suggests authorization may not be properly enforced in the test environment. See TODO.md for remediation.

The LogReaderService automatically redacts sensitive patterns before displaying logs:

Limitation: Patterns are regex-based and may not catch all sensitive data. Custom application secrets with non-standard formats will not be redacted.

Server private keys are:

• Encrypted at rest using Laravel's encrypted cast
• Hidden from serialization ($hidden array)
• Never exposed in API responses or views
• Stored in text column (supports long keys)

The database query component restricts access to read-only operations:

protected const ALLOWED_STATEMENTS = ['SELECT', 'SHOW', 'DESCRIBE', 'EXPLAIN'];

Known Risk: The current implementation only checks the first word, which does not prevent:

• Stacked queries: SELECT 1; DROP TABLE users
• Subqueries with side effects (MySQL stored procedures)

Mitigation: Use a proper SQL parser or prevent semicolons entirely.

The /hub/api/dev/session endpoint exposes:

• Session ID
• User IP address
• User agent (truncated to 100 chars)
• Request method and URL

This is intentional for debugging but could be abused for session hijacking if credentials are compromised.

All API endpoints have rate limits to prevent abuse:

Rate limits are per-user (authenticated) or per-IP (unauthenticated).

The testConnection() method in Servers.php creates a temporary key file:

$tempKeyPath = sys_get_temp_dir().'/ssh_test_'.uniqid();
file_put_contents($tempKeyPath, $server->getDecryptedPrivateKey());
chmod($tempKeyPath, 0600);

Risk: Predictable filename pattern and race condition window between write and use.

Recommendation: Use tempnam() for unique filename, write with restrictive umask.

• StrictHostKeyChecking=no is used for convenience but prevents MITM detection
• BatchMode=yes prevents interactive prompts
• ConnectTimeout=10 limits hanging connections

The RemoteServerManager::connect() method validates workspace ownership before connecting:

if (! $server->belongsToCurrentWorkspace()) {
    throw new SshConnectionException('Unauthorised access to server.', $server->name);
}

This prevents cross-tenant server access.

Route testing is only available in local and testing environments:

public function isTestingAllowed(): bool
{
    return App::environment(['local', 'testing']);
}

This prevents accidental data modification in production.

Routes using DELETE, PUT, PATCH, POST methods are marked as destructive and show warnings in the UI.

Test requests bypass CSRF as they are internal requests. The X-Requested-With: XMLHttpRequest header is set by default.

The SetHadesCookie listener sets a cookie on login:

ApplyIconSettings middleware reads icon-style and icon-size cookies set by JavaScript. These are stored in session for Blade component access.

Risk: Cookie values are user-controlled. Ensure they are properly escaped in views.

Server model uses Spatie ActivityLog for tracking changes:

• Logged fields: name, ip, port, user, status
• Only dirty attributes logged
• Empty logs suppressed

• Sensitive headers hidden: cookie, x-csrf-token, x-xsrf-token
• Sensitive parameters hidden: _token
• Gate restricts to Hades users (production) or all users (local)

• Gate restricts to Hades users
• Notifications configured via config (not hardcoded emails)

When adding new developer tools:

• Enforce Hades authorization in middleware AND component
• Add rate limiting for API endpoints
• Redact sensitive data in output
• Audit destructive operations
• Restrict environment (local/testing) for dangerous features
• Validate and sanitize all user input
• Use prepared statements for database queries
• Clean up temporary files/resources
• Document security considerations

1. Revoke the user's Hades access
2. Rotate HADES_TOKEN environment variable
3. Review audit logs for suspicious activity
4. Check server access logs for SSH activity
5. Consider rotating SSH keys for connected servers

1. Delete the server record immediately
2. Regenerate SSH key on the actual server
3. Review server logs for unauthorized access
4. Update the server record with new key

1. Separate Hades token per environment - Don't use same token across staging/production
2. Regular audit log review - Monitor for unusual access patterns
3. Limit Hades users - Only grant to essential personnel
4. Use hardware keys - For servers, prefer hardware security modules
5. Network segmentation - Restrict admin panel to internal networks
6. Two-factor authentication - Require 2FA for Hades-tier accounts
7. Session timeout - Consider shorter session duration for Hades users