location-history-mcp-server

The primary `index.js` entry point (as defined in `package.json` and implicitly used by default Cloud Run deployments) has several critical security vulnerabilities: 1. **No Authentication for MCP Tools:** The `/sse` and `/message` endpoints, which expose all 15 MCP tools (e.g., `get_location_history`, `list_all_places`, `get_travel_stats`), have no authentication or authorization checks. Any client can connect and call any tool, accessing or manipulating data associated with the `DEFAULT_USER_ID`. 2. **Exposed Debug Endpoints:** Endpoints like `/debug/sample`, `/debug/stats`, `/debug/fix-timestamps`, and `/debug/clear-bad-timestamps` are exposed without any authentication. This allows unauthorized users to read sensitive data samples, view database statistics, or trigger data manipulation for the `DEFAULT_USER_ID`. 3. **Default User ID:** The server largely operates on a hardcoded or defaulted `DEFAULT_USER_ID`. While this might be acceptable for single-user local development, it's highly insecure for any shared or multi-user deployment. 4. **Weak Upload Authentication:** The `/upload` endpoint attempts authentication via a 'Bearer' token or `lifeos_` API key. However, if authentication fails or the token is not a recognized API key, it falls back to the `DEFAULT_USER_ID` for storing data. This means a client could potentially upload data to the default user's account even with an invalid token. While the code includes a separate `http-server-oauth.ts` file which implements OAuth 2.1 and per-request user isolation (which would address these issues), the `deploy-oauth.sh` script, as written, deploys the `index.js` entry point by default, rendering the OAuth configuration ineffective for the running application. Unless the deployment specifically overrides the entry point to `build/http-server-oauth.js`, the insecure `index.js` version will run.