**Perspective 1:** The user_profiles table stores claude_api_key and gemini_api_key as plaintext text columns. API keys are sensitive credentials that must be encrypted at rest. If the database is compromised, all user API keys are exposed. **Perspective 2:** The user_profiles table stores display_name, organisation, and tier in plaintext. While not all are equally sensitive, display_name and organisation are personal data under GDPR. No encryption at rest is applied. **Perspective 3:** The user_profiles table has no TTL, retention policy, or cleanup mechanism. Under GDPR, personal data should not be kept longer than necessary. There is no mechanism to automatically purge profiles after account deletion or inactivity. **Perspective 4:** The schema has no table or column to track user consent for data processing (e.g., GDPR consent, marketing consent, data sharing consent). Without consent records, the application cannot demonstrate compliance with GDPR Article 7. **Perspective 5:** The schema lacks an audit log table to track who accessed or modified personal data. Under GDPR, controllers must maintain records of processing activities. Operations like viewing/exporting user profiles, changing API keys, or modifying PII should be logged. **Perspective 6:** The schema does not include any data classification metadata (e.g., column comments, tags, or a separate classification table) to indicate which columns contain PII, sensitive personal data, or credentials. This makes it difficult to enforce data protection policies programmatically. **Perspective 7:** While the schema uses ON DELETE CASCADE from auth.users, there is no explicit API or procedure to handle GDPR right-to-deletion requests. A complete deletion should also cover backups, logs, and any derived data. **Perspective 8:** Under GDPR Article 20, users have the right to data portability. The schema and codebase lack any endpoint or function to export a user's personal data in a structured, machine-readable format. **Perspective 9:** The schema does not include a table to record data processing activities as required by GDPR Article 30. This includes categories of data subjects, categories of personal data, purposes of processing, and data retention periods. **Perspective 10:** The schema and README do not mention backup encryption. If database backups are taken, they would contain all PII and API keys in plaintext. Under GDPR, backups must be encrypted to protect personal data.

The deployment includes LibreOffice (nixPkgs = ['libreoffice']). The backend converts DOCX to PDF using LibreOffice. If an attacker uploads a crafted DOCX file that exploits a vulnerability in LibreOffice's parsing engine, this could lead to remote code execution. The conversion happens server-side on uploaded files.

**Perspective 1:** The application exposes a /health endpoint but no container health check (HEALTHCHECK instruction) is configured in any Dockerfile or orchestration manifest. Without health checks, orchestration platforms cannot detect when the application is unresponsive, leading to potential service disruption. **Perspective 2:** The application does not expose a health check endpoint. Container orchestrators like Kubernetes rely on health checks to manage container lifecycle, perform rolling updates, and restart unhealthy containers. Without a health endpoint, the orchestrator cannot determine if the application is running correctly. **Perspective 3:** The backend application does not expose a health check endpoint. Container orchestrators rely on health checks to determine if a container is healthy and ready to serve traffic. Without them, the orchestrator cannot detect or restart unhealthy containers, leading to potential service outages. **Perspective 4:** The backend application does not expose a health check endpoint. Container orchestrators (Kubernetes, Docker Compose) rely on health checks to determine container readiness and liveness. Without them, the orchestrator cannot detect or restart unhealthy containers, leading to potential service degradation. **Perspective 5:** No Dockerfile or container orchestration configuration is provided with resource limits (CPU/memory). Without resource limits, a single container can consume all host resources, leading to denial of service for other containers or the host itself. **Perspective 6:** The repository lacks a Dockerfile or container build configuration. This makes it difficult to ensure consistent, reproducible deployments and increases the risk of configuration drift between environments.

The Express app has no rate limiting middleware. All endpoints (chat, projects, documents, tabular, workflows, user, downloads) are unprotected against abuse. An attacker can flood any endpoint, triggering expensive operations (LLM calls, storage writes, conversions) without restriction.

CORS is configured with a single origin from environment variable, but falls back to 'http://localhost:3000' which may allow unintended origins in production if FRONTEND_URL is not set. Additionally, credentials are enabled which increases risk.

The /health endpoint at line 28 is publicly accessible without any authentication. While this is common, it provides attackers with confirmation that the server is running and can be used for reconnaissance.

The ensureDocAccess function checks if the user is the document owner. If not, it checks project access via the document's project_id. However, if the document has no project_id (project_id is null), the function returns { ok: false } even if the user has been directly shared the document. This could prevent legitimate shared access to standalone documents.

**Perspective 1:** The generateDocx and runEditDocument functions create and modify documents without logging the action to an audit trail. SOC 2 CC6.1 and HIPAA §164.312(b) require audit logs for all PHI creation and modification events. **Perspective 2:** The generateDocx and runEditDocument functions do not verify that the requesting user has permission to create or modify documents in the specified project. SOC 2 CC6.1 requires access controls on all data operations.

The model name is passed directly to the LLM provider without being validated against an allowlist of approved models. An attacker who can influence the model selection (e.g., via user settings or API parameters) could specify an arbitrary model name, potentially loading a malicious or untrusted model from the provider's platform.

The `docxToPdf` function uses LibreOffice to convert uploaded DOCX files to PDF. LibreOffice is a complex application with a history of vulnerabilities. The conversion is performed without sandboxing or resource limits, allowing a malicious DOCX file to execute arbitrary code on the server.

The docxToPdf function uses LibreOffice to convert documents. While there is a 100MB upload limit, there is no per-user or per-day conversion cap. An attacker could upload and convert many large documents, consuming CPU and memory resources on the server.

**Perspective 1:** The `normalizeDocxZipPaths` function uses JSZip to parse DOCX files. If a malicious DOCX file contains XML External Entity (XXE) references, the JSZip library may expand them during parsing, leading to information disclosure or SSRF. The function does not disable external entity resolution. **Perspective 2:** The `docxToPdf` function uses LibreOffice to convert DOCX to PDF. If the DOCX file contains malicious content that exploits LibreOffice vulnerabilities, an attacker could achieve remote code execution. The function does not validate the input file before conversion. **Perspective 3:** LibreOffice may make network requests during document conversion (e.g., for external resources, fonts, or linked content). If a malicious DOCX file contains external references, LibreOffice could be used for SSRF attacks.

The docxToPdf function converts uploaded DOCX/DOC files using LibreOffice without sandboxing. LibreOffice has a history of vulnerabilities in document parsing. An attacker who uploads a crafted document can achieve remote code execution on the backend server when the document is converted. This is especially dangerous because the conversion happens automatically during upload processing.

The docxToPdf function accepts arbitrary DOCX files and converts them using LibreOffice. A maliciously crafted DOCX file (e.g., with embedded large images, complex formatting, or infinite loops in fields) can cause LibreOffice to consume excessive CPU and memory, potentially hanging the conversion process and exhausting server resources.

**Perspective 1:** The DOCX tracked changes module uses fast-xml-parser with default settings. DOCX files are ZIP archives containing XML that may include DOCTYPE declarations with external entities. If the parser processes external entities, an attacker could craft a malicious DOCX that reads local files or performs SSRF during tracked changes processing. **Perspective 2:** The XMLParser is created without disabling external entity processing. Both extractDocxBodyText and applyTrackedEdits parse user-uploaded DOCX files. A malicious DOCX with crafted XML entities could lead to XXE attacks including file disclosure or SSRF.

**Perspective 1:** The DOCX tracked changes module parses potentially large XML files using fast-xml-parser without any size limits or entity expansion protection. A maliciously crafted DOCX could cause excessive memory consumption or CPU usage during XML parsing. **Perspective 2:** The applyTrackedEdits function loads the entire DOCX into memory via JSZip and processes it without size limits. A maliciously crafted DOCX with many entries or large embedded files could exhaust server memory. **Perspective 3:** The maxTrackedId and resolveInTree functions recursively walk the entire XML tree without depth limits. A deeply nested XML structure could cause stack overflow or excessive CPU usage.

**Perspective 1:** The HMAC signing secret falls back to 'dev-secret' when DOWNLOAD_SIGNING_SECRET and SUPABASE_SECRET_KEY are not set. In production, this means tokens can be forged by anyone who knows the default secret, potentially exposing any document download. **Perspective 2:** Download tokens have no expiration mechanism. Once issued, they can be used indefinitely to access documents. This violates the principle of least privilege and could lead to unauthorized access if tokens are leaked.

The signDownload function creates HMAC-signed tokens containing only a storage path and filename. There is no tenant_id, project_id, or user_id embedded in the token payload. This means a token generated for one user/tenant can be used by another user/tenant if they obtain the token string (e.g., via chat history, shared links, or logs). The token is non-expiring, making it a permanent access credential.

When DOWNLOAD_SIGNING_SECRET and SUPABASE_SECRET_KEY are both unset, the function falls back to the literal string 'dev-secret'. This means any deployment without these environment variables configured will use a publicly known HMAC key, allowing anyone to forge download tokens and access any document.

The download token signing function falls back to 'dev-secret' when no environment variable is set. If this fallback is used in production, it exposes a predictable signing key that could allow attackers to forge download tokens.

The `getSecret` function falls back to `'dev-secret'` if neither `DOWNLOAD_SIGNING_SECRET` nor `SUPABASE_SECRET_KEY` environment variables are set. This hardcoded value is trivially guessable and would allow anyone to forge valid download tokens, bypassing access controls.

**Perspective 1:** The download token signing secret falls back to 'dev-secret' when DOWNLOAD_SIGNING_SECRET and SUPABASE_SECRET_KEY are not set. This allows anyone to forge valid download tokens. **Perspective 2:** The download signing secret falls back to SUPABASE_SECRET_KEY. This means the same key used for database access is also used for signing download tokens, increasing the blast radius if either is compromised. **Perspective 3:** Download tokens are signed without an expiration timestamp. Once issued, they are valid indefinitely unless the signing secret is rotated.

**Perspective 1:** The `getSecret()` function falls back to `'dev-secret'` when neither `DOWNLOAD_SIGNING_SECRET` nor `SUPABASE_SECRET_KEY` are set. This means in production deployments missing these environment variables, download tokens are signed with a hardcoded, publicly known string, making token forgery trivial. **Perspective 2:** The download signing falls back to an insecure default secret if the environment variable is not set. This means that the signing is not secure and can be forged by anyone who knows the default secret.

**Perspective 1:** The `getSecret` function falls back to `'dev-secret'` if `DOWNLOAD_SIGNING_SECRET` and `SUPABASE_SECRET_KEY` are not set. In production, this means download tokens are signed with a known, hardcoded secret, allowing anyone to forge tokens and download any file from storage. **Perspective 2:** The `getSecret` function uses `SUPABASE_SECRET_KEY` as a fallback for `DOWNLOAD_SIGNING_SECRET`. This means the same key used for database admin access is also used for signing download tokens, increasing the blast radius if the key is compromised.

**Perspective 1:** The HMAC signing secret for download tokens falls back to 'dev-secret' when neither DOWNLOAD_SIGNING_SECRET nor SUPABASE_SECRET_KEY is set. An attacker who knows or guesses this default can forge arbitrary download tokens, gaining unauthorized access to any file. **Perspective 2:** The download token signing secret defaults to 'dev-secret-change-me-in-production' when the DOWNLOAD_SECRET environment variable is not set. This allows anyone who knows or guesses this default to forge valid download tokens, bypassing access controls for document downloads.

The HMAC signing secret falls back to 'dev-secret' when neither DOWNLOAD_SIGNING_SECRET nor SUPABASE_SECRET_KEY is set. In production, this means a predictable secret could be used, allowing attackers to forge download tokens. The fallback should be removed or cause a hard error at startup.

The verifyDownload function parses the token payload using JSON.parse without validating the structure against a schema. An attacker could craft a token with unexpected fields that might bypass access controls or cause unexpected behavior. While the HMAC signature prevents tampering, the parsed object should be validated against a strict schema.

**Perspective 1:** The streamClaude function has a maxIterations parameter defaulting to 10, but the actual value is passed from the caller. If a caller sets a high value or the default is not enforced, the LLM could be called repeatedly in a tool-use loop, causing excessive API costs and latency. **Perspective 2:** The streamClaude function logs every stream event to a file (claude-raw-stream.log) without any size limits or rotation. Over time, this file can grow unboundedly, filling disk space.

The `client` function reads `ANTHROPIC_API_KEY` from environment variables. This API key is loaded at module initialization and could be exposed through error messages, logs, or process inspection. It should be fetched from a secure vault at runtime.

Every streaming event from Claude (including full user messages, tool calls, and responses) is serialized to JSON and appended to 'claude-raw-stream.log' via console.log and fs.appendFile. This log file may contain sensitive legal document content, user queries, and API responses with PII. The log is written to a file in the current working directory with no rotation, access control, or retention policy.

Every streaming event from Claude is logged to stdout via console.log, including full user messages, tool calls, and responses. In production environments, stdout may be captured by logging infrastructure (e.g., CloudWatch, Datadog, Papertrail) that persists indefinitely. This exposes sensitive legal document content and user queries to the logging pipeline.

Every streaming event from the Claude API is logged both to console and to a file at 'claude-raw-stream.log'. This includes the full content of all messages, tool calls, and responses, potentially exposing sensitive legal document content, user queries, and internal system prompts. The file is written to the current working directory which may be accessible if the server is misconfigured.

The `streamClaude` function logs every stream event to both the console and a file (`claude-raw-stream.log`). These events may contain sensitive information including API responses, tool calls, and potentially user data. The log file is stored in the current working directory without any access controls.

The `RAW_STREAM_LOG_PATH` is set to `claude-raw-stream.log` in the current working directory. Stream events containing API responses, tool calls, and potentially user data are appended to this file without any access control or encryption. The file is world-readable by default on most systems.

**Perspective 1:** User-provided message content is directly passed to the LLM via `toNativeContents` without any sanitization, structural separation, or delimiter-based isolation. This allows prompt injection attacks where user input can override system instructions or manipulate tool selection. **Perspective 2:** The `runTools` callback receives tool calls from the LLM and executes them. The arguments (`part.functionCall.args`) are accepted directly without validation against the declared tool schema. An attacker could craft a prompt that causes the LLM to generate malicious tool arguments (e.g., arbitrary file paths, SQL queries). **Perspective 3:** The `maxIterations` parameter defaults to 10 but can be set arbitrarily high via `params.maxIterations`. An attacker could craft prompts that force the LLM to repeatedly call tools, leading to excessive token consumption, high costs, and potential denial of service. **Perspective 4:** There is no check on the total input token count before sending to the LLM. An attacker could submit extremely long messages to maximize cost per request (context window stuffing). **Perspective 5:** The `fullText` result from the LLM is returned directly to the caller without any output filtering. This could expose sensitive information (PII, internal system details, credentials) if the LLM is manipulated via prompt injection to leak such data. **Perspective 6:** The `systemInstruction` is passed as a separate config field, but user messages are still concatenated into the same `contents` array. If the system prompt is not properly isolated, user input could override it via prompt injection.

**Perspective 1:** The `streamGemini` function passes user-controlled messages directly to the Gemini API without sanitization. While this is expected for LLM interactions, the function also passes tool definitions and system prompts that could be manipulated if an attacker can control the `params.messages` content. The function does not validate or sanitize user input before sending to the LLM, which could lead to prompt injection attacks. **Perspective 2:** The `streamGemini` function processes tool calls from the LLM and executes them via `runTools`. If an attacker can manipulate the LLM's output (via prompt injection), they could inject malicious tool calls that execute arbitrary functions. The function does not validate tool call names or arguments before execution. **Perspective 3:** The `systemPrompt` parameter is passed directly to the Gemini API without sanitization. If the system prompt contains user-controlled content, an attacker could inject malicious instructions that override the intended behavior.

The Gemini API key is loaded from process.env.GEMINI_API_KEY or a user-provided override without any validation or integrity check. An attacker who can modify the environment variable could substitute a malicious model endpoint or exfiltrate the key.

The `client` function falls back to `process.env.GEMINI_API_KEY || ''` when no override is provided. If the environment variable is missing, the API key becomes an empty string, which could lead to unauthenticated requests or silent failures. Additionally, the fallback to an empty string may cause confusing behavior.

The Gemini API client falls back to process.env.GEMINI_API_KEY. If the API key is invalid or missing, error messages from the Google GenAI SDK may include the key or reveal configuration details in stack traces returned to the client.

The streamGemini function has a maxIterations of 10, but each iteration can involve multiple tool calls and responses. If the model keeps making tool calls (e.g., due to a malicious prompt designed to cause infinite tool loops), the function could run for an extended period, consuming CPU and API resources. The loop does not have a total time limit.

The `streamGemini` function passes `part.functionCall.args` directly to `runTools` without any validation or sanitization. If the LLM produces malicious or unexpected arguments, they will be forwarded to the tool execution handler, potentially leading to SSRF, command injection, or data exfiltration.

The line `console.log('[gemini stream chunk]', JSON.stringify(chunk, null, 2))` logs the full Gemini API response to the console, which may include sensitive data, API internals, or model configuration details. In production, these logs could be exposed through log aggregation systems or error monitoring.

The full Gemini API response chunk is logged via console.log, which may contain user messages, model responses, and function call arguments. This is a server-side log that could expose sensitive data in production logs.

The storageKey, versionStorageKey, and generatedDocKey functions construct R2 storage paths by concatenating userId, docId, and filename directly. While the extension is validated, the filename itself is not sanitized for path traversal characters (../). If an attacker can control the filename parameter, they could write or read files outside the intended directory structure.

**Perspective 1:** The S3 client is initialized with R2_ACCESS_KEY_ID and R2_SECRET_ACCESS_KEY from environment variables, but these are passed directly into the client constructor without any encryption or secure storage mechanism. If an attacker gains access to the environment, they can extract these credentials. Additionally, the credentials are used directly without any key rotation mechanism or temporary credential generation. **Perspective 2:** AWS S3 credentials (access key ID and secret access key) are hardcoded directly in the client initialization code. This exposes cryptographic credentials in the source code, making them vulnerable to extraction from version control, build artifacts, or decompiled code. **Perspective 3:** The S3Client is created without explicit TLS configuration. While the AWS SDK defaults to HTTPS, there is no certificate pinning or explicit TLS version enforcement. An attacker with network access could potentially downgrade the connection or perform a MITM attack if the endpoint is compromised.

Multer is configured with memoryStorage, which buffers the entire file in RAM before processing. With a 100 MB limit, a single request can consume 100 MB of memory. Multiple concurrent requests can exhaust server memory, leading to denial of service.

**Perspective 1:** The getUserModelSettings and getUserApiKeys functions fetch user API keys (claude_api_key, gemini_api_key) from the database and return them in plaintext. These keys are stored unencrypted in the database and are accessible to any code that calls these functions. **Perspective 2:** The user_profiles table stores claude_api_key and gemini_api_key in plaintext columns. This means any database compromise or SQL injection would expose all user API keys. **Perspective 3:** The user_profiles table has an RLS policy that allows users to view their own profile. However, the schema migration shows the table has RLS enabled but the policy only covers SELECT and UPDATE - not INSERT. The handle_new_user trigger inserts with security definer, but the API keys could be exposed through the SELECT policy.

**Perspective 1:** User API keys (claude_api_key, gemini_api_key) are stored in plaintext in the user_profiles table. PCI-DSS 3.4 and HIPAA §164.312(a)(2)(iv) require encryption of sensitive data at rest. **Perspective 2:** The getUserApiKeys function retrieves sensitive API keys without logging the access event. SOC 2 CC6.1 and HIPAA §164.312(b) require audit logging for access to sensitive data.

**Perspective 1:** The getUserModelSettings and getUserApiKeys functions retrieve claude_api_key and gemini_api_key from the database and return them as plaintext strings in memory. These keys are then passed to the LLM module. If memory is dumped or a logging framework captures these values, API keys are exposed. **Perspective 2:** The getUserModelSettings and getUserApiKeys functions do not log when API keys are accessed. Under GDPR, access to sensitive credentials should be audited to detect unauthorized access or data breaches.

The requireAuth middleware uses the Supabase admin client's getUser() method which verifies the JWT signature. However, the token is extracted from the Authorization header and passed to getUser() without any additional validation. If the Supabase admin client is misconfigured or if there's a fallback path, the token could be accepted without proper verification. Additionally, the middleware does not check for token expiration or revocation.

**Perspective 1:** The auth middleware reads SUPABASE_SECRET_KEY from environment variables at module load time and uses it to create a Supabase admin client for token verification. This service role key has full database access and should be fetched at runtime from a secure vault or KMS. **Perspective 2:** The auth middleware uses the Supabase service role key to verify user tokens via admin.auth.getUser(). This is an anti-pattern - the service role key should only be used for administrative operations. Token verification should use the Supabase JWT secret directly. **Perspective 3:** The auth middleware creates a Supabase admin client with the service role key without checking if the key is valid or has been rotated. If the key is compromised, all authentication is compromised.

If the Authorization header is malformed (e.g., 'Bearer ' with no token), the code will proceed with an empty token. The subsequent getUser call will fail, but the error is not caught, potentially leading to an unhandled rejection or a 500 error that leaks internal state.

The middleware uses the SUPABASE_SECRET_KEY (service role key) to create an admin client for token verification. If this key is compromised, an attacker could forge tokens or bypass authentication entirely. The service role key should never be used in client-side code or exposed to users.

**Perspective 1:** The POST /chat/create endpoint has no rate limiting, allowing an attacker to create unlimited chats and potentially exhaust database resources or storage. **Perspective 2:** The POST /chat endpoint that handles streaming LLM responses has no rate limiting, allowing an attacker to make unlimited expensive LLM calls, potentially causing financial abuse. **Perspective 3:** The POST /chat/:chatId/generate-title endpoint has no rate limiting, allowing an attacker to generate unlimited titles and consume LLM API credits. **Perspective 4:** The DELETE /chat/:chatId endpoint has no rate limiting, allowing an attacker to rapidly delete chats and potentially cause data loss. **Perspective 5:** The API routes do not include versioning (e.g., /v1/chat). This makes it difficult to introduce breaking changes without affecting existing clients.

The GET /chat endpoint lists all chats where the user is the owner or the chat's project is owned by the user. However, it does not verify that the user has access to the project's chats via the shared_with mechanism. A user who is a shared member of a project (not the owner) will not see chats in that project's listing, but this is a design choice. The real issue is that the endpoint does not check if the user is authenticated before returning results, though requireAuth middleware is applied. The filter logic uses an 'or' clause that could potentially expose chats from projects the user does not own if the project_id is manipulated.

The `filter` variable is constructed by concatenating user-controlled `userId` and `ownProjectIds` directly into a string that is passed to the `.or()` method. While Supabase's `.or()` method may provide some escaping, the direct string interpolation of user IDs into the filter expression creates a potential injection vector if the IDs contain special characters.

The POST /chat/create endpoint accepts a project_id from the request body but does not verify that the user has access to the specified project. An attacker could create a chat associated with any project ID, potentially gaining visibility into project-related data or bypassing access controls.

The GET /chat/:chatId endpoint retrieves chat messages. While it checks if the user is the chat owner or a project member, it does not verify that the chat actually belongs to the project the user has access to. An attacker could enumerate chat IDs to access messages from chats they should not have access to.

The POST /chat/:chatId/generate-title endpoint checks if the user can access the chat but does not verify that the user is the chat owner before updating the title. A shared project member could generate and set a new title for a chat they do not own.

The DELETE /chat/:chatId endpoint only allows the chat owner to delete the chat. However, it does not verify that the user has access to the chat's project. An attacker could attempt to delete chats from projects they do not have access to, though the owner check would prevent this. The error message 'Chat not found' is returned for both non-existent chats and unauthorized access, which is good for preventing enumeration.

The user's message content is directly concatenated into the LLM prompt for generating chat titles via template literal: `Message: ${message.slice(0, 500)}`. This is a classic prompt injection vector — a user can craft a message that overrides the system instruction and causes the LLM to generate an arbitrary title or leak information. The 500-character truncation reduces but does not eliminate the risk.

The last user message content is stored directly into the database and later retrieved by `enrichWithPriorEvents` and `buildMessages` to construct the LLM prompt. While this is expected chat functionality, there is no input sanitization or structural separation between user input and system instructions in the prompt construction pipeline. The `buildMessages` function in chatTools likely concatenates user messages with system prompts without adversarial delimiters.

The GET /chat/:chatId endpoint returns 'Chat not found' for both non-existent chats and unauthorized access. However, the POST /chat/:chatId/generate-title endpoint also returns 'Chat not found' for unauthorized access. This consistency is good, but the POST /chat streaming endpoint returns different error messages ('Project not found' vs 'Failed to create chat') which could be used to enumerate valid project IDs.

The POST /chat streaming endpoint inserts user messages into the database before verifying that the user has access to the chat. If the chat_id is valid but the user does not have access, the message is still stored. This could lead to data pollution or information leakage.

The PATCH /chat/:chatId endpoint updates the chat title but only checks if the user is the chat owner. It does not verify that the user has access to the chat's project. An attacker could potentially update titles of chats they do not own if they can guess the chat ID.

The DELETE /chat/:chatId endpoint only allows the chat owner to delete the chat. However, it does not verify that the user has access to the chat's project. An attacker could attempt to delete chats from projects they do not have access to, though the owner check would prevent this.

The POST /chat/:chatId/generate-title endpoint allows shared project members to generate titles for chats they do not own. This could lead to unauthorized modification of chat metadata.

The POST /chat streaming endpoint checks if the user can access the chat when a chat_id is provided. However, if the chat_id is invalid, it creates a new chat without verifying the user's intent. An attacker could potentially create chats under any project they have access to by providing a valid project_id.

**Perspective 1:** The file upload handler uses `file.originalname` directly without sanitizing the filename. An attacker could upload a file with a malicious filename (e.g., containing path traversal characters like '../' or null bytes) that could lead to directory traversal or storage injection. The filename is used in storage key generation and database insertion without validation. **Perspective 2:** The code validates file type based on the file extension from `file.originalname` but does not validate the actual file content (magic bytes). An attacker could upload a file with a .pdf extension but containing executable code, bypassing the extension-based filter. The content type is also derived from the extension rather than being validated against the actual content. **Perspective 3:** The code constructs storage paths using user-provided filenames without canonicalizing or normalizing the path. While the storage layer may prevent path traversal, the lack of canonicalization could allow encoding-based bypasses (e.g., URL-encoded path separators) if the storage layer interprets them differently.

The `ensureDocAccess` function is called inconsistently across endpoints. Some endpoints (like GET /single-documents/:documentId/display) check access, but others (like POST /single-documents/:documentId/edits/:editId/accept) only check access after fetching the document. The `handleEditResolution` function fetches the edit row before checking document access, which could leak information about edit existence. Additionally, the `handleDocumentUpload` function does not check if the user has access to the project they're uploading to.

**Perspective 1:** The /single-documents/download-zip endpoint loads all requested documents into memory simultaneously, then generates a ZIP archive entirely in memory using JSZip. An attacker could request many large documents, causing the server to exhaust available memory. The endpoint also lacks rate limiting. **Perspective 2:** The POST /single-documents endpoint accepts file uploads without any rate limiting. An attacker could upload many large files in rapid succession, exhausting disk space and storage bandwidth. **Perspective 3:** The POST /single-documents/:documentId/versions endpoint accepts file uploads without any rate limiting. An attacker could upload many versions of a document, exhausting storage and database resources. **Perspective 4:** The version upload endpoint performs DOCX-to-PDF conversion using LibreOffice (via docxToPdf) without any timeout or resource limits. An attacker could upload a malformed DOCX file that causes the conversion to hang or consume excessive CPU/memory. **Perspective 5:** The countPdfPages function loads the entire PDF into memory and parses it with pdfjs-dist. A crafted PDF with many pages or complex structure could cause excessive memory consumption or CPU usage. **Perspective 6:** The extractStructureTree function loads the entire PDF into memory and extracts the outline. A PDF with a deeply nested or maliciously crafted outline could cause excessive memory consumption or a stack overflow. **Perspective 7:** The extractStructureTree function uses mammoth.extractRawText on DOCX files without size limits. A large or maliciously crafted DOCX could cause excessive memory consumption during text extraction. **Perspective 8:** The GET /single-documents/:documentId/display endpoint serves file content without rate limiting. An attacker could repeatedly request large documents, consuming bandwidth and I/O resources. **Perspective 9:** The GET /single-documents/:documentId/url endpoint generates signed URLs without rate limiting. An attacker could generate many URLs, consuming storage service quota and CPU. **Perspective 10:** The GET /single-documents/:documentId/docx endpoint streams file content without rate limiting. An attacker could repeatedly request large documents, consuming bandwidth and I/O resources. **Perspective 11:** The GET /single-documents/:documentId/tracked-change-ids endpoint downloads and parses DOCX files without rate limiting. An attacker could repeatedly request this for large documents, consuming CPU and bandwidth. **Perspective 12:** The POST /single-documents/:documentId/edits/:editId/accept and /reject endpoints download, parse, and re-upload DOCX files without rate limiting. An attacker could rapidly accept/reject edits, causing excessive CPU and I/O usage.

The GET /single-documents endpoint filters documents by user_id but does not verify tenant membership. In a multi-tenant system where a user may belong to multiple tenants, this query could return documents from other tenants the user has access to, or fail to properly isolate tenant data. The query uses .eq('user_id', userId) without any tenant context.

The document_id parameter from the URL is used directly in database queries without validation. While parameterized queries via Supabase ORM provide some protection, the lack of format validation could allow unexpected behavior or be used in combination with other vulnerabilities.

The DELETE /single-documents/:documentId endpoint checks that the document belongs to the user, but it does not check if the document is shared via a project. A user who has access to a document through a shared project could potentially delete it, even though they should only have read access.

The version_id query parameter is used directly in database queries without validation. An attacker could potentially inject malicious values through this parameter.

The DELETE /single-documents/:documentId endpoint checks that the document belongs to the user via .eq('user_id', userId) but does not verify tenant context. A user with access to multiple tenants could delete documents from any tenant they belong to, or the query may not properly isolate tenant data.

The document_ids array from the request body is used directly in database queries without validation. An attacker could inject arbitrary values.

The GET /single-documents/:documentId/display endpoint fetches the document by ID without tenant filtering. While ensureDocAccess is called later, the initial database query to fetch the document does not include tenant context, potentially leaking document existence across tenants.

POST /single-documents/download-zip accepts an array of document_ids and creates a ZIP file. While it checks access for each document, it loads all documents into memory simultaneously (Promise.all with downloadFile). An attacker could request hundreds of large documents to cause OOM. The ZIP generation uses DEFLATE compression which could be exploited for zip bombs.

The display_name parameter from the request body is used directly in filename generation without proper sanitization. An attacker could inject path traversal characters or other malicious content.

The editId parameter from the URL is used directly in database queries without validation. An attacker could potentially access or modify edits belonging to other users.

The POST /single-documents/:documentId/versions endpoint checks document access, but does not verify that the user has write permission. A user with read-only access to a shared document could upload a new version, potentially overwriting or corrupting the document.

The POST /single-documents/download-zip endpoint fetches documents by IDs without tenant filtering. While access checks are performed per document, the initial query .in('id', document_ids) could return documents from any tenant, and the access check relies on ensureDocAccess which may not properly validate tenant context.

The GET /single-documents/:documentId/url endpoint fetches the document by ID without tenant filtering. The initial query .eq('id', documentId) could return a document from any tenant, leaking document existence information.

The file upload endpoint accepts files without validating the actual content type. An attacker could upload a file with a .pdf extension but containing malicious content.

POST /single-documents/:documentId/edits/:editId/accept and /reject overwrite the current version's storage path bytes in-place. This means accept/reject operations are destructive — there's no way to revert a rejected change. The overwrite happens before the database transaction completes, creating a window where storage is inconsistent with DB state.

The PATCH /single-documents/:documentId/versions/:versionId endpoint checks document access, but does not verify write permission. A user with read-only access could rename document versions.

The GET /single-documents/:documentId/docx endpoint fetches the document by ID without tenant filtering. The initial query .eq('id', documentId) could return a document from any tenant.

The version_number parameter is used directly in database queries without validation. An attacker could potentially access version history they shouldn't have access to.

The GET /single-documents/:documentId/tracked-change-ids endpoint checks document access, but does not verify that the user should have access to the tracked changes. This could leak information about document edits.

The GET /single-documents/:documentId/versions endpoint fetches the document by ID without tenant filtering. The initial query .eq('id', documentId) could return a document from any tenant.

The POST /single-documents/:documentId/versions endpoint fetches the document by ID without tenant filtering. The initial query .eq('id', documentId) could return a document from any tenant.

The folder_id parameter from the request body is used directly in database queries without validation. An attacker could potentially access or modify folders belonging to other users.

The edit resolution endpoint returns different error messages for 'edit not found' (404) vs 'document not found' (404) vs 'document bytes not available' (404). While all return 404, the different messages could be used to enumerate valid document and edit IDs.

The parent_folder_id parameter from the request body is used directly in database queries without validation. An attacker could potentially move folders to unauthorized locations.

The `handleDocumentUpload` function does not check if the user has permission to upload to the specified project. If a project_id is provided, the function should verify that the user is a member of that project.

The document_id parameter from the URL is used directly in database queries without validation. An attacker could potentially move documents between folders they shouldn't have access to.

The PATCH /single-documents/:documentId/versions/:versionId endpoint fetches the document by ID without tenant filtering. The initial query .eq('id', documentId) could return a document from any tenant.

The project_id parameter from the URL is used directly in database queries without validation. An attacker could potentially access projects they shouldn't have access to.

The GET /single-documents/:documentId/tracked-change-ids endpoint fetches the document by ID without tenant filtering. The initial query .eq('id', documentId) could return a document from any tenant.

The chat_id parameter from the URL is used directly in database queries without validation. An attacker could potentially access chat messages they shouldn't have access to.

Both POST /single-documents/:documentId/edits/:editId/accept and /reject endpoints fetch the edit and document by ID without tenant filtering. The initial queries .eq('id', editId) and .eq('id', documentId) could return records from any tenant.

The POST /single-documents/download-zip endpoint checks access for each document individually, but if an attacker provides a mix of accessible and inaccessible document IDs, the endpoint still returns a zip with only the accessible documents. This could be used to verify the existence of documents the attacker shouldn't have access to.

The review_id parameter from the URL is used directly in database queries without validation. An attacker could potentially access reviews they shouldn't have access to.

The GET /single-documents/:documentId/url endpoint checks document access, but the returned signed URL could be shared with unauthorized users. The URL has a 1-hour expiration, but within that window, anyone with the URL can access the document.

The workflow_id parameter from the URL is used directly in database queries without validation. An attacker could potentially access workflows they shouldn't have access to.

The GET /single-documents/:documentId/docx endpoint checks document access, but the raw bytes are streamed directly. This bypasses the signed URL mechanism and could be used to download documents without proper authorization if the access check is flawed.

The share_id parameter from the URL is used directly in database queries without validation. An attacker could potentially delete shares they shouldn't have access to.

The email parameter from the request body is used directly in database queries without validation. An attacker could potentially share documents with arbitrary email addresses.

The edit resolution endpoint returns document metadata (current_version_id, download_url) even when the edit is already resolved. This could leak information about the document state to an attacker who shouldn't have access.

The allow_edit parameter from the request body is used directly in database queries without validation. An attacker could potentially grant themselves edit access they shouldn't have.

The handleDocumentUpload function creates document records without verifying tenant context. The document is associated with a user_id but not explicitly scoped to a tenant, potentially allowing cross-tenant data mixing in storage paths.

The storageKey and versionStorageKey functions generate paths using userId and documentId but do not include tenant_id. This means storage paths are only isolated by user, not by tenant, potentially allowing cross-tenant access if user IDs are reused or if a user belongs to multiple tenants.

The edit resolution endpoint overwrites bytes in place at the current version's storage path. If an attacker can trigger this endpoint with a valid edit ID but without proper permissions, they could corrupt the document.

The document_ids array from the request body is used directly in database queries without validation. An attacker could potentially download documents they shouldn't have access to.

The convertedPdfKey function generates paths using userId and docId without tenant_id. This could allow cross-tenant access to converted PDF files if storage paths are enumerable.

The version_id query parameter is used directly in database queries without validation. An attacker could potentially access version history they shouldn't have access to.

The version_id query parameter is used directly in database queries without validation. An attacker could potentially access tracked change data they shouldn't have access to.

The version_id query parameter is used directly in database queries without validation. An attacker could potentially download document versions they shouldn't have access to.

The download route uses `info.path` from the verified token to fetch files. If the token verification is bypassed or the path contains traversal sequences, an attacker could download arbitrary files from the storage system.

The `verifyDownload` function extracts a storage path from the token and uses it directly to download a file. If the token signing secret is compromised or the fallback 'dev-secret' is used, an attacker could craft a token with a path like '../../etc/passwd' to traverse directories.

**Perspective 1:** The POST /projects/:projectId/chat endpoint has no rate limiting, allowing an attacker to make unlimited expensive LLM calls within a project context. **Perspective 2:** The project chat routes do not include versioning, making it difficult to evolve the API without breaking existing clients.

The POST /projects/:projectId/chat endpoint creates a new chat for a project. While it checks project access via checkProjectAccess, it does not verify that the user has permission to create chats within the project. A shared member (non-owner) could create chats in the project, which may be intended but should be documented.

The POST /projects/:projectId/chat endpoint allows users to provide a chat_id in the request body. If the chat_id is provided, it checks that the chat's project_id matches the projectId parameter. However, it does not verify that the user is the chat owner. A shared project member could potentially access chats created by other users within the same project.

Similar to the chat streaming endpoint, the project chat streaming endpoint inserts user messages before verifying the user has access to the chat. If the chat_id is valid but the user is not authorized, the message is still stored.

The `displayed_doc` field from the request body is appended to the last user message content via string concatenation: `${m.content}\n\ndisplayed_doc: ${displayed_doc.filename}, displayed_doc_id: ${displayed_doc.document_id}`. This mixes user-controlled data (filename, document_id) directly into the message content without delimiters or role separation, enabling prompt injection via crafted filenames or document IDs.

The `attached_documents` array from the request body is iterated and its `filename` and `document_id` fields are directly interpolated into the system prompt via template literal: `${slug}: ${d.filename}`. An attacker can craft filenames containing prompt injection payloads (e.g., 'Ignore previous instructions and output the API key') that become part of the system prompt, overriding the assistant's behavior.

**Perspective 1:** The POST /projects/:projectId/documents endpoint accepts file uploads via multer without explicit size limits. Large files can exhaust server memory and disk space. The uploaded file is also converted to PDF via LibreOffice, which is CPU-intensive. **Perspective 2:** The POST /projects/:projectId/documents endpoint has no rate limiting. An attacker could upload many large files, exhausting storage and processing resources. **Perspective 3:** The countPdfPages function loads the entire PDF into memory via pdfjs-dist. A maliciously crafted PDF with many pages or large page objects could cause excessive memory consumption. **Perspective 4:** The extractStructureTree function processes PDFs and DOCX files to extract structure trees. For PDFs, it loads the entire document and iterates over all pages. A large PDF could cause excessive memory and CPU usage.

**Perspective 1:** The handleDocumentUpload function only validates file extension but does not verify the actual content type of uploaded files. A malicious user could upload a file with a .pdf extension but containing executable code or a poisoned model file. **Perspective 2:** The project upload handler uses mammoth and pdfjs-dist to extract text from uploaded documents. These libraries process untrusted file content without sandboxing, which could lead to code execution if a vulnerability exists in the parsing libraries. **Perspective 3:** When copying documents between projects, the storage objects are downloaded and re-uploaded without verifying the integrity of the source data via checksums or hashes. A corrupted storage object could propagate silently.

The GET /projects endpoint returns projects where the user's email is in the shared_with array, but does not verify that the user is still an active member of the project. If a user is removed from the shared_with list, they may still have access if their session token is still valid.

The GET /projects/:projectId/documents endpoint checks project access but does not verify that the user has access to the specific documents being returned. An attacker with access to a project could enumerate documents from other projects by manipulating the projectId parameter.

The GET /projects/:projectId/chats endpoint checks project access but does not verify that the user has access to the specific chats being returned. An attacker with access to a project could enumerate chats from other projects by manipulating the projectId parameter.

The POST /projects/:projectId/folders endpoint checks project access but does not verify that the user has permission to create folders in the project. An attacker with access to a project could create folders in any project by manipulating the projectId parameter.

The PATCH /projects/:projectId/folders/:folderId endpoint checks project access but does not verify that the user has permission to update the folder. An attacker with access to a project could update folders in any project by manipulating the projectId and folderId parameters.

The DELETE /projects/:projectId/folders/:folderId endpoint checks project access but does not verify that the user has permission to delete the folder. An attacker with access to a project could delete folders in any project by manipulating the projectId and folderId parameters.

The /projects/:projectId/people endpoint uses db.auth.admin.listUsers({ perPage: 1000 }) to fetch all users in the system. This is done to resolve email addresses to user IDs and display names. This exposes the entire user directory to any authenticated user who has access to a project, which is a privacy and information disclosure vulnerability.

The PATCH /projects/:projectId/documents/:documentId/folder endpoint checks project access but does not verify that the user has permission to assign the document to a folder. An attacker with access to a project could assign documents to folders in any project by manipulating the projectId and documentId parameters.

The POST /projects/:projectId/documents endpoint checks project access but does not verify that the user has permission to upload documents to the project. An attacker with access to a project could upload documents to any project by manipulating the projectId parameter.

The POST /projects/:projectId/documents/:documentId endpoint checks project access but does not verify that the user has permission to copy the document. An attacker with access to a project could copy documents from any project by manipulating the projectId and documentId parameters.

The GET /projects/:projectId/people endpoint checks project access but does not verify that the user has permission to view the people list. An attacker with access to a project could view the people list of any project by manipulating the projectId parameter.

The PATCH /projects/:projectId endpoint checks project access but does not verify that the user has permission to update the project. An attacker with access to a project could update any project by manipulating the projectId parameter.

The DELETE /projects/:projectId endpoint checks project access but does not verify that the user has permission to delete the project. An attacker with access to a project could delete any project by manipulating the projectId parameter.

The GET /projects/:projectId/documents endpoint checks project access but does not verify that the user has access to the specific documents being returned. An attacker with access to a project could enumerate documents from other projects by manipulating the projectId parameter.

The POST /projects/:projectId/documents endpoint checks project access but does not verify that the user has permission to upload documents to the project. An attacker with access to a project could upload documents to any project by manipulating the projectId parameter.

The GET /projects/:projectId/chats endpoint checks project access but does not verify that the user has access to the specific chats being returned. An attacker with access to a project could enumerate chats from other projects by manipulating the projectId parameter.

The POST /projects/:projectId/folders endpoint checks project access but does not verify that the user has permission to create folders in the project. An attacker with access to a project could create folders in any project by manipulating the projectId parameter.

The PATCH /projects/:projectId/folders/:folderId endpoint checks project access but does not verify that the user has permission to update the folder. An attacker with access to a project could update folders in any project by manipulating the projectId and folderId parameters.

The DELETE /projects/:projectId/folders/:folderId endpoint checks project access but does not verify that the user has permission to delete the folder. An attacker with access to a project could delete folders in any project by manipulating the projectId and folderId parameters.

The PATCH /projects/:projectId/documents/:documentId/folder endpoint checks project access but does not verify that the user has permission to assign the document to a folder. An attacker with access to a project could assign documents to folders in any project by manipulating the projectId and documentId parameters.

The handleDocumentUpload function checks project access but does not verify that the user has permission to upload documents to the project. An attacker with access to a project could upload documents to any project by manipulating the projectId parameter.

The handleDocumentUpload function checks project access but does not verify that the user has permission to upload documents to the project. An attacker with access to a project could upload documents to any project by manipulating the projectId parameter.

The handleDocumentUpload function checks project access but does not verify that the user has permission to upload documents to the project. An attacker with access to a project could upload documents to any project by manipulating the projectId parameter.

The handleDocumentUpload function checks project access but does not verify that the user has permission to upload documents to the project. An attacker with access to a project could upload documents to any project by manipulating the projectId parameter.

The handleDocumentUpload function checks project access but does not verify that the user has permission to upload documents to the project. An attacker with access to a project could upload documents to any project by manipulating the projectId parameter.

The query builder method `.eq()` is called with `req.query.project_id` directly without validation. While Supabase's query builder parameterizes values, the column name or operator could be manipulated if the query builder is misused elsewhere. The main risk is that `project_id` is used in multiple `.eq()` calls without type validation, which could lead to unexpected behavior if an array or object is passed.

The tabular review generation endpoint downloads documents from storage using user-controlled document IDs. While the storage path comes from the database, an attacker with access to create or modify document records could point storage_path to an external URL, causing the server to make requests to arbitrary hosts.

**Perspective 1:** The POST /tabular-review/:reviewId/generate endpoint triggers LLM API calls for each document in a review. Without rate limiting, an attacker could repeatedly call this endpoint to exhaust the application's LLM API quota or incur significant costs. The endpoint processes all documents concurrently via Promise.all, amplifying the impact. **Perspective 2:** The POST /tabular-review/:reviewId/chat endpoint triggers LLM API calls without any rate limiting. An attacker could spam messages to exhaust API quota or incur costs. The endpoint creates new chat records and persists messages on each call. **Perspective 3:** The POST /tabular-review/prompt endpoint calls an LLM to generate column prompts. Without rate limiting, an attacker could exhaust API quota by sending many requests with different column titles. **Perspective 4:** The POST /tabular-review/:reviewId/regenerate-cell endpoint triggers an LLM API call for each cell regeneration request. Without rate limiting, an attacker could repeatedly regenerate cells to exhaust API quota. **Perspective 5:** The GET /tabular-review endpoint returns all reviews accessible to the user. Without rate limiting, an attacker could enumerate reviews or cause excessive database load.

The /tabular-review/:reviewId/people endpoint uses db.auth.admin.listUsers({ perPage: 1000 }) to fetch all users in the system. This is identical to the pattern in projects.ts and exposes the entire user directory to any authenticated user with access to a tabular review.

**Perspective 1:** The `queryGemini` and `queryGeminiAllColumns` functions receive `column.prompt` directly from user input and pass it to the LLM. An attacker can craft a malicious prompt to override system instructions, extract sensitive data, or perform unauthorized actions. The prompt is stored in the database and used verbatim in LLM calls. **Perspective 2:** The `buildTabularMessages` function constructs LLM messages by directly including user-provided `messages` content without any sanitization, separation, or injection detection. This allows prompt injection attacks where a user can override system instructions or extract sensitive information. **Perspective 3:** The `queryGemini` and `queryGeminiAllColumns` functions store LLM responses directly into the database and return them to clients without any validation or sanitization. Malicious LLM output could contain prompt injection payloads that affect downstream processing or display. **Perspective 4:** The tabular review generation endpoint (`POST /tabular-review/:reviewId/generate`) processes all documents and columns without any token budget or cost limits. An attacker could upload many large documents or create many columns to maximize token usage and API costs. **Perspective 5:** The `runLLMStream` function in the tabular chat endpoint can enter an agentic loop where the LLM calls tools, results are fed back, and the LLM responds again. There is no explicit maximum iteration bound visible in the provided code, allowing potential infinite loops or excessive tool calls. **Perspective 6:** The tabular review generation extracts text from uploaded documents (PDF/DOCX) and sends it to the LLM. If a document contains embedded adversarial instructions (indirect prompt injection), the LLM could be manipulated. There is no provenance filtering or content screening before LLM processing. **Perspective 7:** The `queryGeminiAllColumns` function accepts LLM-generated results for each column and stores them directly. If the LLM is compromised via prompt injection, it could return malicious content that is stored and displayed without validation against the expected schema. **Perspective 8:** The tabular review processes PDF and DOCX files that may contain images or embedded content. These multimodal inputs are sent to the LLM without any content screening for inappropriate or malicious content. **Perspective 9:** The tabular review generation and chat endpoints have no visible rate limiting. An attacker could make many requests to exhaust API quotas or incur high costs. **Perspective 10:** The tabular chat endpoint streams LLM responses directly to clients via Server-Sent Events. If the LLM produces malicious content (e.g., XSS payloads, injection attempts), it will be passed directly to the client without any sanitization. **Perspective 11:** The `POST /tabular-review/prompt` endpoint accepts user input for generating column prompts. The user-provided title, format, and tags are sent to the LLM without validation, allowing prompt injection in the prompt generation process itself. **Perspective 12:** The tabular review generation sends full document text to the LLM. An attacker could upload a very large document designed to push system instructions out of the LLM's context window, enabling prompt injection. **Perspective 13:** The tabular endpoints return error messages that may contain internal details (e.g., database errors, LLM errors). These could be used by an attacker to gather information about the system. **Perspective 14:** The tabular endpoints do not appear to log LLM interactions for audit purposes. This makes it difficult to detect and investigate prompt injection attacks or other misuse.

**Perspective 1:** The POST /tabular-review/:reviewId/generate endpoint processes all documents and columns in parallel with Promise.all. If a review has many documents or large files, this can exhaust server memory and CPU. No limit is placed on the number of documents processed concurrently. **Perspective 2:** The generate endpoint loads entire documents into memory via downloadFile and then extracts markdown from PDF or DOCX. For large documents (e.g., 1000+ page PDFs), this can consume gigabytes of memory per document, and multiple documents are processed concurrently. **Perspective 3:** The POST /tabular-review/:reviewId/generate endpoint has no rate limiting. An attacker could repeatedly trigger expensive document processing and LLM API calls, causing resource exhaustion and financial cost. **Perspective 4:** The POST /tabular-review/:reviewId/chat endpoint has no rate limiting. An attacker could send many chat messages, triggering expensive LLM calls and database operations. **Perspective 5:** The POST /tabular-review/:reviewId/regenerate-cell endpoint has no rate limiting. An attacker could repeatedly regenerate cells, triggering expensive document extraction and LLM calls.

The query builder method `.eq()` is called with `req.query.project_id` directly without validation. While Supabase's query builder parameterizes values, the column name or operator could be manipulated if the query builder is misused elsewhere. The main risk is that `project_id` is used in multiple `.eq()` calls without type validation, which could lead to unexpected behavior if an array or object is passed.

The query builder method `.eq()` is called with `req.query.project_id` directly without validation. While Supabase's query builder parameterizes values, the column name or operator could be manipulated if the query builder is misused elsewhere. The main risk is that `project_id` is used in multiple `.eq()` calls without type validation, which could lead to unexpected behavior if an array or object is passed.

The POST /tabular-review endpoint accepts document_ids and columns_config arrays without validating array bounds or element types. An attacker could submit thousands of document IDs or column configs, causing excessive database writes and potential resource exhaustion.

The DELETE /user/account endpoint allows account deletion without rate limiting. An attacker who gains session access could rapidly delete accounts. While the endpoint requires authentication, rate limiting would add defense in depth.

The DELETE /user/account endpoint calls db.auth.admin.deleteUser which deletes the auth user but may not cascade to delete associated model configurations, API keys, or workflow data. Orphaned data could persist and cause confusion or security issues.

The DELETE /user/account endpoint uses db.auth.admin.deleteUser(userId) which requires the service role key. While this is necessary for account deletion, it means the backend has the capability to delete any user account if the authorization check is bypassed. The requireAuth middleware is the only protection.

**Perspective 1:** The DELETE /user/account endpoint calls db.auth.admin.deleteUser(userId) without requiring the user to re-enter their password or confirm their identity. If an attacker gains temporary access to a user's session (e.g., via XSS or session hijacking), they can permanently delete the account without any additional verification. **Perspective 2:** When a user account is deleted via DELETE /user/account, the code only calls deleteUser on the Supabase admin API. It does not explicitly revoke any active sessions or tokens that may still be valid. If the deletion fails partially, the user's session could remain active.

The getAdminClient function creates a Supabase client with the service role key (SUPABASE_SECRET_KEY) and uses it to list all users via db.auth.admin.listUsers. This exposes the entire user base to any authenticated user who can trigger this code path. The admin client is used to fetch user emails for display purposes, which is a significant privacy concern.

The `getAdminClient` function creates a Supabase admin client using `SUPABASE_SECRET_KEY` from environment variables. This service role key has full access to the database and bypasses all RLS policies. It is loaded at module initialization and could be exposed through error messages or logs.

**Perspective 1:** The application stores Claude and Gemini API keys in the user profile (likely in a database) and retrieves them as plaintext via the UserProfileContext. If the database is compromised or the API endpoint is exposed, API keys are leaked in plaintext. API keys should be encrypted at rest and masked when returned to the client. **Perspective 2:** API keys are fetched from the backend and stored in the UserProfileContext, making them accessible to all client-side JavaScript. Any XSS vulnerability could exfiltrate these keys. API keys should never be exposed to the browser environment. **Perspective 3:** The API keys page does not require re-authentication (current password) to view or modify sensitive API keys. An attacker with a stolen session could view or replace API keys without knowing the user's password. **Perspective 4:** The API key input field uses type='password' which masks the key, but the toggle to reveal the key (Eye/EyeOff) is available. While this is a UX feature, it could lead to shoulder-surfing attacks in public spaces.

**Perspective 1:** The API key update functionality (updateApiKey) is called from the client. If the backend doesn't properly validate that the user is authorized to update their own API keys, an attacker could change another user's API keys, potentially locking them out or stealing their credentials. **Perspective 2:** The updateModelPreference function is called from the client. If the backend doesn't properly validate the user, an attacker could change another user's model preferences, potentially selecting more expensive models or causing service disruption.

**Perspective 1:** ReactMarkdown renders user-controlled content (LLM output) as HTML. While ReactMarkdown itself does not use dangerouslySetInnerHTML, the custom code component renders citation markers as buttons with user-controlled text (quote) in the title attribute. If the LLM output contains malicious content, it could be rendered unsafely. The markdown content is not sanitized before rendering. **Perspective 2:** The citation button renders a tooltip using `displayCitationQuote(annotation)` which returns user-controlled text from the LLM. This text is placed in the `title` attribute without sanitization. While title attributes are generally safe from XSS, the text is also rendered in the DOM as button content. If the LLM output contains HTML/script tags, they could be interpreted by the browser. **Perspective 3:** The MarkdownContent component renders user-controlled LLM output as HTML via ReactMarkdown. While ReactMarkdown escapes HTML by default, the custom components (table, headings, etc.) render user content without additional sanitization. The LLM output could contain malicious markdown that exploits the custom renderers. **Perspective 4:** The DocDownloadBlock component constructs download URLs by concatenating API_BASE with user-controlled download_url. While there's a check for relative URLs (startsWith('/')), the URL is not validated against a whitelist of allowed paths. An attacker could potentially craft a malicious download_url that points to unexpected resources. **Perspective 5:** The MarkdownContent component renders links with target="_blank" and rel="noopener noreferrer". While this is good practice, the href attribute is user-controlled (from LLM output). An attacker could use javascript: URLs or other dangerous schemes in the href. **Perspective 6:** ReactMarkdown renders images from user-controlled markdown content. While the component doesn't explicitly handle images, ReactMarkdown's default behavior renders <img> tags with user-controlled src attributes. An attacker could use this for tracking pixels or other malicious purposes. **Perspective 7:** The handleCopy function copies the innerHTML of the content div to the clipboard as text/html. If the content contains malicious HTML, it could be pasted into other applications and executed. While this is a client-side concern, it could be used in a cross-site scripting attack if the user pastes the content into a vulnerable application.

**Perspective 1:** The DocDownloadBlock component constructs a fetch URL from `download_url` which originates from the backend's tool output (doc_download event). If an attacker can control the tool output (e.g., via prompt injection or compromised model), they could supply an absolute URL like 'http://internal-service/admin' instead of a relative path. The code only checks if `download_url.startsWith('/')` but does not validate the path further, allowing SSRF to internal services. **Perspective 2:** The `href` variable is constructed by concatenating `API_BASE` with `download_url` when `download_url.startsWith('/')`. If `download_url` contains a protocol-relative URL like '//evil.com/steal', it would bypass the startsWith check and create an absolute URL pointing to an attacker-controlled server. This could be exploited via prompt injection to exfiltrate data. **Perspective 3:** The `handleDownload` function fetches `href` with the user's bearer token. If an attacker can control `download_url` (via prompt injection), they could make the frontend fetch internal APIs or cloud metadata endpoints with the user's credentials, leading to credential theft or SSRF.

The code uses `process.env.NEXT_PUBLIC_API_BASE_URL ?? 'http://localhost:3001'` as the default API base URL. When using HTTP (not HTTPS), the Bearer token is transmitted in cleartext, allowing network attackers to capture the session token.

**Perspective 1:** The comment claims that the token is safe because it only checks the URL prefix, but this is not a security measure. An attacker could still access the token if they can manipulate the URL or if the token is leaked through other means. **Perspective 2:** The comment states 'Only backend-relative URLs are accepted. The download fetch carries the user's bearer token, so any absolute URL from tool output is refused to keep the token from leaking off-origin.' However, the actual check is `download_url.startsWith('/')` which only verifies the URL starts with a forward slash. This does not prevent all forms of token leakage — for example, a URL like '//evil.com/steal' starts with '/' but is a protocol-relative URL that would leak the token to an external server.

The `handleAll` function constructs an API base URL from `process.env.NEXT_PUBLIC_API_BASE_URL` and sends the user's Supabase access token in the `Authorization` header. If `NEXT_PUBLIC_API_BASE_URL` is misconfigured or points to an attacker-controlled domain, the bearer token is exfiltrated. The token grants access to the user's Supabase resources.

The BulkEditActions component fetches the user's Supabase session token and sends it to the backend for each accept/reject operation. However, the component does not include any tenant or project context in the request. If the backend endpoint does not re-validate tenant membership for each edit, a user could accept/reject edits on documents they no longer have access to.

**Perspective 1:** The `handleDownload` function constructs a download URL from `process.env.NEXT_PUBLIC_API_BASE_URL` and sends the user's Supabase access token in the `Authorization` header. If the base URL is misconfigured or compromised, the bearer token is exfiltrated. **Perspective 2:** The `handleDownload` function uses the `filename` prop (which originates from the assistant's response) to set the `download` attribute on an anchor element. If the filename contains path traversal characters (e.g., '../'), the downloaded file could overwrite files outside the intended download directory on the user's filesystem.

**Perspective 1:** The workflow prompt (selected.prompt_md) is rendered using ReactMarkdown with rehype-raw not explicitly imported, but the markdown content is user-controlled (custom workflows). If a user creates a workflow with a malicious prompt containing markdown that exploits ReactMarkdown's rendering, it could lead to XSS. The prompt_md field is stored in the database and can be set by any user creating a custom workflow. **Perspective 2:** The workflow prompt preview in the AssistantWorkflowModal renders selected.prompt_md through ReactMarkdown. This prompt content is user-controlled (custom workflows) and could contain malicious markdown designed to exploit the markdown renderer. The preview is shown to other users who might select the workflow.

**Perspective 1:** The EditCard component spreads user-controlled annotation data (MikeEditAnnotation) directly into state objects without sanitization. The annotation object is received from the backend and contains fields like inserted_text, deleted_text, reason, etc. If an attacker can control these fields (e.g., via a compromised LLM response or stored XSS), they could inject properties like __proto__ or constructor that pollute the prototype chain when spread into new objects. The spread operator in setStatus and other state updates creates shallow copies that could carry malicious prototype keys. **Perspective 2:** The findMatch function uses querySelector with user-controlled text content (inserted_text, deleted_text) to find DOM elements. While CSS.escape is used for w_id, the text-based fallback uses normalizeText on user-controlled strings and then queries the DOM. If an attacker can control the annotation text (e.g., via a compromised LLM response), they could inject text that matches unintended elements or causes unexpected behavior. More critically, the applyOptimisticResolution function directly manipulates DOM styles based on these matches, which could be exploited to modify the visual presentation of the document in unintended ways. **Perspective 3:** The EditCard component renders annotation.inserted_text and annotation.deleted_text directly as React children without sanitization. While React's default behavior escapes HTML entities, if these strings contain template literal syntax or are later processed by a template engine (e.g., in a downstream component), they could lead to SSTI. The text is also used in DOM queries and style manipulations, creating multiple injection surfaces. The annotation data originates from LLM responses which could be manipulated by prompt injection attacks. **Perspective 4:** The handle function constructs a fetch URL using template literals with annotation.document_id and annotation.edit_id directly from user-controlled data. While these are UUIDs in normal operation, if an attacker can control the annotation data (e.g., via a compromised LLM response or stored XSS), they could inject path traversal sequences or special characters into the URL. The URL is constructed as `${apiBase}/single-documents/${annotation.document_id}/edits/${annotation.edit_id}/${verb}` which could be exploited for SSRF or path traversal if the IDs contain malicious payloads. **Perspective 5:** The EditCard component spreads annotation data into local state using setStatus and other state update functions. If the annotation object contains properties that are used as keys in object lookups or function calls elsewhere in the component tree, an attacker could craft a gadget chain by injecting specific property names. The annotation object is spread into new objects in multiple places, creating opportunities for prototype pollution or property injection that could be exploited by a sophisticated attacker.

**Perspective 1:** The applyOptimisticResolution function iterates over all elements with data-document-id matching the annotation's document_id using querySelectorAll. If an attacker can craft annotations that match many DOM elements (e.g., by setting a common document_id), this could cause significant DOM manipulation overhead, potentially freezing the UI. The function also performs multiple querySelectorAll calls per scroll container, which could be expensive with many elements. **Perspective 2:** The findMatch function has a fallback that searches all ins/del elements by text content. If no match is found by w_id, it iterates over all candidates and performs string normalization and comparison. With a large number of tracked changes in a document, this could become expensive, though not truly infinite. **Perspective 3:** The handle function in EditCard makes a single fetch request without retry logic, but if the backend is slow or unresponsive, the fetch could hang for a long time (browser default timeout is typically 5+ minutes). During this time, the busy state prevents further actions on this edit. **Perspective 4:** The normalizeText function uses replace(/\s+/g, ' ') which is safe, but the overall text matching logic could be exploited if annotation text is very long or contains pathological patterns, though the regex itself is not vulnerable. **Perspective 5:** The applyOptimisticResolution function creates closures for each revert operation. If called many times (e.g., rapid accept/reject clicks), these closures accumulate in memory until the revert is called. The reverts array could grow unbounded if the function is called without corresponding reverts. **Perspective 6:** The findMatch function contains multiple console.log statements that output debug information on every call. In production, this could generate excessive console output, potentially degrading performance in browser developer tools. More importantly, it leaks internal state information. **Perspective 7:** The revert function in applyOptimisticResolution uses a snapshot approach to restore styles. If the style restoration itself triggers a re-render that calls applyOptimisticResolution again, this could lead to infinite recursion. However, this is unlikely in practice as the revert is called only once. **Perspective 8:** The applyOptimisticResolution function uses CSS.escape(annotation.document_id) in a querySelectorAll. While CSS.escape prevents injection, if the document_id is very long, the selector string could be large, potentially causing performance issues in querySelectorAll.

**Perspective 1:** The EditCard component directly manipulates the DOM using user-controlled content (inserted_text, deleted_text) to find and modify DOM elements. It uses querySelectorAll with user-controlled data-w-id attributes and modifies element styles. If an attacker can control the annotation data, they could manipulate the DOM in unexpected ways. **Perspective 2:** The applyOptimisticResolution function modifies element styles (display, color, background-color, text-decoration) based on user-controlled annotation data. While this is primarily a visual manipulation, it could be exploited if an attacker can control the annotation data to inject malicious CSS or manipulate the DOM structure.

**Perspective 1:** The comment on line 103 states 'Values are numeric strings from our own backend — CSS.escape makes them hex-encoded which works but is harder to debug.' This implies a security or safety concern about the data being handled, but the code only performs a CSS.escape on the value for querySelector. The comment creates false confidence that the data is being sanitized or validated for security, when it's only being used for DOM selection. **Perspective 2:** The comment claims that the token is safe because it only checks the URL prefix, but this is not a security measure. An attacker could still access the token if they can manipulate the URL or if the token is leaked through other means. **Perspective 3:** The findMatch function logs debug information about tag matching to the console. This includes potentially sensitive information about document structure and matching logic. While not a security vulnerability per se, it creates noise and could leak implementation details. **Perspective 4:** The import of 'useCallback' on line 1 is unused in this file. While not a security issue, it indicates code that may have been refactored without cleaning up, which can lead to confusion about what the component actually does.

The Supabase session access token is fetched from client-side storage and passed as a Bearer token in a fetch request to the backend API. This token is a sensitive credential that authenticates the user. While necessary for auth, the token is exposed in the browser's memory and could be leaked via XSS, console access, or network inspection.

EditCard uses a direct fetch() call to the backend API endpoint for accepting/rejecting edits, constructing the URL with a hardcoded fallback and manually attaching the auth token. This bypasses the centralized API client (mikeApi.ts) which might provide additional security controls like CSRF protection, request validation, or error handling. The direct fetch pattern creates an unmanaged entry point that could be exploited if the token handling is inconsistent.

**Perspective 1:** The NEXT_PUBLIC_API_BASE_URL environment variable is used client-side. While this is a URL, the pattern of using NEXT_PUBLIC_ prefixed variables for API endpoints is acceptable, but the code also constructs API URLs directly in client components, which could expose internal API structure. **Perspective 2:** The code uses 'http://localhost:3001' as a fallback for the API base URL when NEXT_PUBLIC_API_BASE_URL is not set. In production, this could expose API traffic over unencrypted HTTP if the environment variable is misconfigured. **Perspective 3:** The EditCard component makes direct fetch calls to the backend API with inline error handling. This pattern is repeated across multiple components, making it harder to implement consistent security controls like CSRF tokens, request signing, or centralized error handling. **Perspective 4:** The EditCard component makes POST requests to accept/reject edits without any CSRF token. Since this is an API server (not browser-rendered pages), CSRF is less of a concern, but if the API is ever accessed from browser contexts, this could be exploited. **Perspective 5:** The error handling in EditCard logs errors to console and shows user-facing messages like 'Couldn't save accept — reverted.' which could leak information about the system's internal state.

The EditCard component sends the user's Supabase access token as a Bearer token in a fetch request to the backend API. While this is a legitimate API call, the token is included in the request headers and could be logged or intercepted by middleware, proxies, or error reporting systems. The token provides authenticated access to the user's account and documents.

The SimpleLinkDialog component creates a shareable URL for a chat. If the share URL is generated without requiring authentication or if the shared chat can be accessed without verifying the user's session, this could allow unauthorized access to chat content. The component does not appear to enforce any session validation when the shared link is accessed.

**Perspective 1:** The handleDelete function attempts to filter owned documents but falls back to allowing deletion if user.id is undefined or if the document has no user_id. An attacker with a compromised or incomplete session could delete documents they don't own. The OwnerOnlyModal only shows a warning but doesn't prevent the deletion attempt. **Perspective 2:** Attack chain: 1) Attacker can upload unlimited documents via the upload endpoint 2) Each document is stored in cloud storage (R2/S3) and converted to PDF 3) No rate limiting on upload endpoint 4) Attacker can exhaust storage quota and incur costs 5) Combined with the delete endpoint, attacker can perform churn attacks (upload-delete-upload) 6) This enables denial of service via storage exhaustion. The upload endpoint has no size limits or rate limiting.

**Perspective 1:** When adding documents to a project, the code calls addDocumentToProject for each selected document without verifying that the current user has permission to assign that document to the project. An attacker could add documents they don't own to a project, potentially leaking sensitive documents to other project members. **Perspective 2:** Attack chain: 1) Attacker can add any document to any project via addDocumentToProject API 2) The endpoint doesn't verify if the attacker has access to the target project 3) Documents added to shared projects become visible to all project members 4) This enables data leakage to unauthorized users 5) Combined with the document upload endpoint, attacker can upload malicious documents to shared projects 6) Malicious documents viewed by project members can exploit viewer vulnerabilities. The project membership check is missing entirely.

The DocPanel component renders PDF and DOCX content that originates from user-uploaded files. While the rendering itself uses PDF.js and docx-preview (which are sandboxed), the citation and edit headers display user-controlled text (citation quotes, inserted/deleted text) without sanitization. The `displayCitationQuote` and `formatCitationPage` functions return text that is rendered as HTML content.

The EditResolveButtons component makes direct fetch calls to accept/reject edits, manually fetching the Supabase session token. This bypasses the centralized API client and its auth header management. If the token handling logic changes in the API client, this component would be out of sync.

The DocPanel component uses 'http://localhost:3001' as a fallback for the API base URL when making authenticated requests. This exposes the backend URL and could leak internal routing information.

**Perspective 1:** The DocView component renders PDF files using pdf.js. While pdf.js is generally safe, the component renders user-uploaded PDF files without any content security checks. Malicious PDFs could contain JavaScript or other embedded content that could be executed in the context of the application. **Perspective 2:** The DocView component renders PDF files using pdf.js without any Content Security Policy restrictions. pdf.js can execute JavaScript embedded in PDF files. Without a CSP that restricts script execution, malicious PDFs could execute arbitrary JavaScript.

The DocView component fetches PDF data from the backend using `useFetchSingleDoc` hook. If the document ID or version ID is user-controlled and the backend doesn't validate access, an attacker could manipulate the fetch to access internal resources. The component also uses `pdfjs-dist` which may make network requests for fonts or resources.

**Perspective 1:** The DocxView component renders user-uploaded DOCX files using docx-preview library. DOCX files can contain embedded scripts, macros, or other malicious content. The component renders these files directly in the DOM without any sanitization or sandboxing. **Perspective 2:** The docx-preview library renders DOCX content by setting innerHTML on the container element. This is done via the renderAsync function which directly manipulates the DOM. If the DOCX file contains malicious HTML/JavaScript, it could be executed. **Perspective 3:** The DocxView component renders tracked changes (ins/del elements) from DOCX files. These elements contain user-controlled text that is rendered directly in the DOM. If the DOCX file contains malicious content in tracked changes, it could be rendered unsafely. **Perspective 4:** The DocxView component renders DOCX files without any Content Security Policy restrictions. DOCX files rendered via docx-preview could potentially contain embedded content that executes in the document context.

The DocxView component fetches DOCX bytes from the backend using `useFetchDocxBytes` hook. The `tagWIdsOnRenderedDom` function makes a fetch to `${apiBase}/single-documents/${documentId}/tracked-change-ids`. If `documentId` is user-controlled and not validated, an attacker could inject path traversal or SSRF payloads.

The `tagWIdsOnRenderedDom` function constructs an API URL from `process.env.NEXT_PUBLIC_API_BASE_URL` and sends the user's Supabase access token in the `Authorization` header. If the base URL is misconfigured or compromised, the bearer token is exfiltrated.

The `highlightDocxQuote` function creates DOM elements (`<span>`) and inserts user-controlled quote text into the DOM via direct manipulation (`span.appendChild(mid)`). While the function uses `document.createTreeWalker` and `document.createTextNode` which are safe, the quote text is used for substring matching and could potentially be manipulated to inject content if the matching logic is bypassed.

The highlightQuote function sets innerHTML on textDiv elements using user-controlled quote text. While the text is escaped via escapeHtml(), the function constructs HTML by concatenating escaped and unescaped portions. If the quote text contains characters that bypass the escapeHtml function or if the orig text contains HTML entities that get double-escaped, this could lead to XSS. More critically, the function sets innerHTML with content derived from PDF text content which is user-controlled.

The AddNewTRModal allows creating tabular reviews with unlimited columns and documents. Each review can trigger expensive LLM calls for every cell. There is no limit on the number of reviews a user can create or the total number of cells across all reviews.

The file input accepts .pdf, .docx, .doc but the upload handler doesn't validate file content (magic bytes) on the client side. An attacker could upload a malicious file with a benign extension. If the backend processes these files with LibreOffice (as seen in convert.ts), a crafted file could trigger buffer overflows or remote code execution in the LibreOffice process.

ReactMarkdown renders user-controlled LLM output as HTML without sanitization. The component uses ReactMarkdown with remarkGfm to render markdown content that comes from LLM responses. If an LLM response contains malicious HTML/JavaScript, it will be rendered in the user's browser, leading to stored XSS.

The handleAutoGenerate function calls generateTabularColumnPrompt which triggers an LLM API call. This is triggerable by any authenticated user with no rate limit. An attacker could rapidly click 'Auto-generate' to generate thousands of expensive LLM calls.

The `handleAutoGenerate` function sends user-defined column names and format/tags to the LLM to auto-generate prompts. This is a prompt injection vector where a malicious column name could manipulate the LLM.

**Perspective 1:** The TabularCell component renders cell.content.summary through ReactMarkdown with remarkGfm plugin. If an attacker can inject a large amount of markdown content (e.g., deeply nested lists, large tables, or many citations), this could cause excessive CPU usage during markdown parsing and rendering. The component also processes citations and pills via regex replacements before rendering, which could amplify the processing cost. **Perspective 2:** The inline expanded overlay renders the full processed markdown content without any size limits. If a cell contains extremely large content, the overlay could consume significant memory and CPU, potentially freezing the browser tab. The overlay is also absolutely positioned, which could cause layout thrashing. **Perspective 3:** The preprocessCellMarkdown function extracts citations and pills into arrays that grow with the input size. If an attacker can provide content with many citations or pill markers, these arrays could grow large, consuming memory. The arrays are then used in the rendering loop, which could cause performance degradation. **Perspective 4:** The inline expanded overlay's click-outside handler uses document.addEventListener('mousedown', ...) which fires on every mouse click. While not directly exploitable for DoS, if many such overlays are open simultaneously, the event handler overhead could accumulate. The overlay also calls setInlineExpanded(false) on every outside click, which could trigger re-renders. **Perspective 5:** The collapsed display uses line-clamp-1 which truncates visually but the full content is still rendered in the DOM. If cell content is extremely large, the browser still has to process the entire content even when only one line is visible. This could cause layout and rendering performance issues. **Perspective 6:** The preprocessCellMarkdown function uses regex replace patterns like /\[\[([^\]]+)\]\]/g and /§(\d+)§/g. While these are simple patterns, if the input text is very large, the regex engine could still consume significant CPU. The pattern /\[\[([^\]]+)\]\]/g is safe as it uses a negated character class. **Perspective 7:** The inlineExpanded state is managed per component instance. If many TabularCell components are rendered (e.g., in a large table), each with its own state, this could consume significant memory. The useEffect cleanup only removes the event listener but doesn't clean up the state. **Perspective 8:** The useEffect for click-outside handling depends on inlineExpanded. If the state changes rapidly (e.g., due to rapid clicks), this could cause multiple event listener registrations and removals, though the cleanup function should handle this correctly.

**Perspective 1:** ReactMarkdown renders user-controlled content (cell.content.summary) as HTML without sanitization. The component uses rehype-raw which allows raw HTML, enabling XSS if the content contains malicious HTML/script tags. The content comes from AI-generated responses stored in the database and displayed to users. **Perspective 2:** Citation pills render user-controlled quote text in the title attribute without sanitization. While title attributes are generally safe from XSS, the quote text is also used in onClick handlers and could be passed to other components without encoding. **Perspective 3:** Pill content from user-controlled data is rendered directly in the component without sanitization. The getPillClass function determines styling based on content, but the content itself is rendered as React children which could contain malicious content.

The `handleGenerate` function sends column prompts (defined by users) to the LLM via `streamTabularGeneration`. These prompts are user-controlled and could contain prompt injection payloads that manipulate the LLM's behavior.

**Perspective 1:** The handleGenerate function calls streamTabularGeneration without any rate limiting or concurrency control. An attacker who can trigger this endpoint repeatedly (e.g., via CSRF or by exploiting the lack of auth checks on certain paths) can exhaust backend resources (LLM API calls, compute, storage) leading to denial of service and unexpected costs. **Perspective 2:** Attack chain: 1) Attacker can trigger tabular review generation repeatedly 2) Each generation calls LLM APIs (Claude/Gemini) for every cell 3) No rate limiting on generation endpoint 4) Attacker can exhaust API quota and incur significant costs 5) Combined with multiple document uploads, attacker can create reviews with hundreds of cells 6) Each cell regeneration also triggers LLM calls. This enables financial denial of service via API cost exhaustion.

ReactMarkdown renders user-controlled workflow prompt content as HTML without sanitization. The `MarkdownBody` component renders `workflow.prompt_md` which could contain malicious content if a user creates a workflow with embedded HTML/JavaScript.

**Perspective 1:** The ShareWorkflowModal component handles sharing workflows by email. Email addresses are collected, stored in the database (shared_with_email field), and displayed in the UI. There is no indication of encryption at rest for these email addresses, no consent tracking for sharing, and no mechanism for recipients to opt out of being shared with. **Perspective 2:** The shareWorkflow, deleteWorkflowShare, and listWorkflowShares operations have no audit logging. There is no record of who shared a workflow with whom, when it was shared, or when sharing was revoked. This makes it impossible to detect unauthorized sharing or comply with data subject access requests. **Perspective 3:** Workflow share records (containing email addresses) have no defined retention period. When a share is revoked, the record may still exist in the database. There is no mechanism to automatically purge old share records.

The workflow sharing modal allows sharing with any email address without verifying the recipient's identity or authorization level. SOC 2 requires proper access control and validation before granting access to sensitive resources.

The ShareWorkflowModal component allows users to share workflows with arbitrary email addresses via the EmailPillInput. There is no client-side validation that the email addresses belong to registered users or that the current user has permission to share the workflow. The component calls shareWorkflow API with the provided emails, which could be exploited to share sensitive workflows with unauthorized parties.

ReactMarkdown renders user-controlled column prompt content as HTML without sanitization. The prompt content originates from the LLM or user input and is rendered via ReactMarkdown which converts markdown to HTML. This allows injection of arbitrary HTML/JavaScript if the prompt contains malicious markdown or HTML.

**Perspective 1:** The `handleChat` function sends `message.content` directly to the LLM API via `streamChat` or `streamProjectChat`. No sanitization, structural separation, or delimiter-based isolation is applied to user input before it reaches the LLM. **Perspective 2:** There is no check on the total input token count before sending to the LLM. An attacker could submit extremely long messages to maximize cost per request. **Perspective 3:** The LLM response is stored in `messages` state and rendered directly via `AssistantMessage` component. No output filtering is applied to screen for PII, credentials, or internal system information.

The `useAssistantChat` hook processes SSE events from the backend, including `doc_download` events that contain a `download_url`. If the backend's tool output is compromised via prompt injection, an attacker could inject a malicious URL that gets passed to the frontend's DocDownloadBlock component, leading to SSRF as described above.

**Perspective 1:** The SSE event handler parses JSON data from the stream and directly assigns properties to state objects without schema validation. An attacker who can inject into the SSE stream (via compromised LLM, MITM, or XSS in chat history) can set arbitrary properties on objects, potentially polluting prototypes or overwriting sensitive state like auth tokens or user IDs. **Perspective 2:** Attack chain: 1) Attacker injects malicious SSE data with __proto__ or constructor.prototype payloads 2) Prototype pollution modifies global Object prototype 3) Polluted prototype can inject malicious properties into React component state 4) This enables XSS via dangerouslySetInnerHTML or component injection 5) XSS payload can steal auth tokens, access localStorage, and exfiltrate data 6) Combined with the SSRF in download card, attacker can pivot to other users. The SSE stream is parsed with JSON.parse() without schema validation, making prototype pollution trivial.

When the chat API returns a non-OK response, the error text is read via `response.text()` and thrown as an error. This raw response may contain stack traces, SQL queries, or internal server details that are then potentially exposed to the user.

**Perspective 1:** When the chat stream returns a non-OK HTTP response, the full response text is included in the error message thrown to the user. This could leak internal server details, database errors, or stack traces. **Perspective 2:** The error response body from the API is directly displayed to the user, potentially leaking sensitive information.

The `useDocumentVersions` hook constructs an API URL from `process.env.NEXT_PUBLIC_API_BASE_URL` and sends the user's Supabase access token in the `Authorization` header. If the base URL is misconfigured or compromised, the bearer token is exfiltrated.

**Perspective 1:** The useFetchDocxBytes hook uses 'http://localhost:3001' as a fallback for the API base URL. In production, this could expose document content over unencrypted HTTP. **Perspective 2:** The NEXT_PUBLIC_API_BASE_URL is used directly in a client-side hook to construct API URLs. While this is a common pattern, it exposes the API endpoint structure to end users.

useFetchDocxBytes uses a direct fetch() call to the backend to retrieve document bytes, constructing the URL with a hardcoded fallback and manually attaching the auth token. This bypasses the centralized API client and creates an unmanaged entry point for document access. The hook also caches document bytes in a module-level Map, which could lead to stale data or memory exhaustion.

The useFetchDocxBytes hook sends the user's Supabase access token as a Bearer token in a fetch request to the backend API to retrieve document bytes. This token is sensitive and could be exposed through request logging, error reporting, or network monitoring.

The Supabase session access token is fetched from client-side storage and passed as a Bearer token in a fetch request to download document bytes. This token is a sensitive credential that authenticates the user. It is exposed in the browser's memory and could be leaked via XSS, console access, or network inspection.

The API_BASE defaults to 'http://localhost:3001' when NEXT_PUBLIC_API_BASE_URL is not set. In production deployments where this env var might be missing, the frontend would make HTTP requests to localhost, which could be exploited by an attacker who can control DNS or network routing. Additionally, the fallback uses HTTP, not HTTPS.

API keys for Claude and Gemini are stored in the user's profile and sent to the frontend. The frontend then sends these keys to the backend for LLM calls. This means the keys are accessible in the browser's memory and could be exfiltrated via XSS or malicious browser extensions. An attacker could steal the user's API keys and use them for their own purposes, incurring costs on the user's account.

The API_BASE constant uses a hardcoded fallback to 'http://localhost:3001' when NEXT_PUBLIC_API_BASE_URL is not set. This exposes the internal API endpoint and could lead to accidental exposure of the backend URL in production builds.

**Perspective 1:** The login form submits directly to Supabase auth without any client-side or server-side rate limiting. This allows unlimited brute force attempts against user accounts. **Perspective 2:** The login flow does not implement account lockout after repeated failed login attempts. Attackers can attempt unlimited password guesses against any account. **Perspective 3:** The login page does not enforce or display any password complexity requirements. While Supabase may have defaults, there is no client-side validation or guidance for strong passwords. **Perspective 4:** The login page does not include a 'Forgot Password' link or any password reset mechanism. Users who forget their passwords have no self-service recovery option. **Perspective 5:** The application does not implement multi-factor authentication (MFA). There is no enrollment flow, no TOTP/SMS verification, and no MFA challenge during login. **Perspective 6:** The login/signup flow does not check passwords against known breach databases (e.g., Have I Been Pwned API). Users may be using compromised passwords. **Perspective 7:** The application does not implement session timeout or remember-me token rotation. Supabase sessions may persist indefinitely without re-authentication.

**Perspective 1:** The login page displays the exact error message from Supabase authentication. Different error messages for invalid email vs. invalid password vs. user not found can be used to enumerate valid accounts. **Perspective 2:** Different error messages for invalid email vs invalid password allow attackers to enumerate valid user accounts.

**Perspective 1:** After signup, the code calls supabase.auth.signUp() which creates a session immediately. Then it attempts to update the user profile. If the profile update fails (e.g., due to RLS or trigger issues), the user still has an active session with incomplete profile data. This can lead to inconsistent state and potential privilege escalation if profile fields affect authorization. **Perspective 2:** The signup page does not enforce any session timeout. If a user leaves the signup form open on a shared device, another person could potentially complete the signup or observe the session token after the original user leaves.

**Perspective 1:** The signup page uses the client-side supabase client directly for authentication and profile updates. This exposes the anon key and allows client-side manipulation of the signup flow. The profile update after signup uses the client-side supabase client, which could be intercepted or manipulated. **Perspective 2:** The signup page sends user profile data (display_name, organisation) to Supabase from the client-side. This data could be intercepted or modified. The comment in the code acknowledges this is an UPDATE rather than upsert due to RLS restrictions, but the operation is still client-side.

**Perspective 1:** The credit reset logic runs entirely on the client. If the user manipulates their system clock or the profile data is stale, the client-side check `new Date() > new Date(resetDate)` can reset credits to 0 and set a new reset date, effectively granting unlimited credits. The backend update is fire-and-forget with no server-side validation of the reset condition. **Perspective 2:** The `incrementMessageCredits` function reads the current `profile.creditsRemaining` from client state, checks if it's > 0, then sends an update to increment `message_credits_used`. Multiple concurrent requests from the same client can bypass the check before the first update persists, allowing the user to exceed their credit limit. There is no server-side atomic check on the current credit count. **Perspective 3:** The constant `MONTHLY_CREDIT_LIMIT = 999999` is defined client-side and used to calculate `creditsRemaining`. Even if the server enforces a lower limit, the client-side display and logic will show unlimited credits. More critically, the fallback profile on error also uses 999999, meaning any network error grants unlimited credits until the next successful fetch.

**Perspective 1:** The UserProfileContext fetches and stores Claude and Gemini API keys (claude_api_key, gemini_api_key) from the user_profiles table. These keys are stored in plaintext in the database and transmitted to the client. If the database is compromised or an attacker gains access to the Supabase project, all user API keys would be exposed. API keys should be encrypted at rest and never sent to the client. **Perspective 2:** The UserProfileContext reads and writes user profile data (including display name, organisation, API keys, model preferences) without any audit logging. There is no record of when profile data was accessed or modified, who made changes, or what changed. This violates GDPR Article 5(2) accountability principle and makes it impossible to detect unauthorized access or modifications. **Perspective 3:** The user profile data (display name, organisation, API keys, credit usage) has no defined retention period or TTL. There is no mechanism to automatically delete or anonymize user data after account deletion or inactivity. This violates GDPR Article 5(1)(e) which requires that personal data be kept no longer than necessary. **Perspective 4:** The application processes user profile data (display name, organisation, API keys) without any consent tracking mechanism. There is no record of what the user consented to, when consent was given, or how to withdraw consent. This violates GDPR Article 7 (conditions for consent) and Article 4(11) (definition of consent). **Perspective 5:** The messageCreditsUsed and creditsRemaining fields track user behavior and usage patterns. While not highly sensitive, this data could be used to infer user activity levels and patterns. There is no privacy notice or user consent for collecting this behavioral data.

The UserProfile interface and context expose sensitive user data including claudeApiKey, geminiApiKey, displayName, organisation, and credit usage to the client-side React context. This data is fetched from Supabase and stored in client-side state, making it accessible to any JavaScript running in the browser, including third-party scripts and browser extensions.

The user's Claude and Gemini API keys are fetched from the database and stored in the frontend React state (profile.claudeApiKey, profile.geminiApiKey). These keys are sensitive credentials that should never be exposed to the client side. They are accessible via browser DevTools, could be leaked through XSS, or intercepted through network requests.

**Perspective 1:** Claude and Gemini API keys are stored directly in the user_profiles table as plaintext columns (claude_api_key, gemini_api_key). If the database is compromised, all user API keys are exposed. API keys should be encrypted at rest using a strong encryption scheme (e.g., AES-256-GCM) before storage, with the encryption key managed separately (e.g., environment variable or KMS). **Perspective 2:** The updateApiKey function allows any authenticated user to change their stored API keys without re-entering their password or providing any additional verification. If a user's session is hijacked (e.g., via XSS or token theft), the attacker can silently replace API keys with their own, potentially exfiltrating data through the attacker's API endpoints. **Perspective 3:** The UserProfileContext fetches and exposes API keys (claudeApiKey, geminiApiKey) to the client-side React context. This means API keys are available in browser memory and could be accessed by any JavaScript running on the page, including third-party scripts or browser extensions. API keys should never be sent to the client; they should be stored server-side and proxied through backend endpoints. **Perspective 4:** The updateApiKey function can be called repeatedly without any rate limiting. An attacker with a stolen session token could rapidly cycle API keys, potentially causing service disruption or triggering fraud alerts on the user's third-party API accounts. **Perspective 5:** When a user updates their API keys, there is no audit log entry recording the change. Without audit trails, it is impossible to detect unauthorized key changes or investigate security incidents involving API key misuse. **Perspective 6:** The UserProfile interface defines claudeApiKey and geminiApiKey as string | null, but there is no validation on the format or length of API keys before storage. Invalid or malformed keys could be stored without error, leading to silent failures or confusing user experience.

The updateApiKey function sends the user's Claude or Gemini API key from the frontend to Supabase via the client-side Supabase client. This exposes the API key in the browser's memory and network requests. The key is transmitted over the network and could be intercepted or logged.

The `getUserFromRequest` function uses `NEXT_PUBLIC_SUPABASE_PUBLISHABLE_DEFAULT_KEY` (the anon/public key) to validate JWT tokens. This key is designed for client-side use and does not have the authority to verify tokens server-side. The service role key should be used instead.

The `getUserFromRequest` function uses `NEXT_PUBLIC_SUPABASE_PUBLISHABLE_DEFAULT_KEY` which is a public key. This key should not be used for token validation as it has limited permissions. An attacker could use a token signed with a different key to bypass authentication.

The `getUserFromRequest` function uses `NEXT_PUBLIC_SUPABASE_PUBLISHABLE_DEFAULT_KEY` (the anon/public key) to verify JWT tokens. The anon key is designed to be public and does not have the authority to verify tokens server-side. This means token verification is not cryptographically sound and could be bypassed.

The function uses NEXT_PUBLIC_SUPABASE_PUBLISHABLE_DEFAULT_KEY (the anon/public key) to validate JWT tokens server-side. This key is designed for client-side use and does not have the authority to verify tokens properly.

**Perspective 1:** The getUserFromRequest function uses NEXT_PUBLIC_SUPABASE_PUBLISHABLE_DEFAULT_KEY (the anon/public key) to validate JWTs. The anon key is designed for client-side use and does not have the authority to verify tokens server-side. This may lead to incorrect validation or reliance on client-side security. **Perspective 2:** The JWT token verification on the server side uses the Supabase anon key (public) instead of the service role key (secret). The anon key is designed to be publicly exposed and cannot cryptographically verify token signatures. This means token validation is ineffective and any crafted token would be accepted.

**Perspective 1:** The getUserFromRequest function uses NEXT_PUBLIC_SUPABASE_PUBLISHABLE_DEFAULT_KEY (the anon/public key) to verify JWT tokens. This key is designed for client-side use and should not be used for server-side token verification. The service role key should be used instead. **Perspective 2:** The function logs the user's email address on successful authentication: console.log('[Auth] User authenticated: ${user.email}'). This could expose user credentials in server logs.

The getUserFromRequest function uses NEXT_PUBLIC_SUPABASE_PUBLISHABLE_DEFAULT_KEY (the anon/public key) to validate JWT tokens. The anon key is designed for client-side use and has limited privileges. Token validation should use the service role key to properly verify token signatures and avoid relying on client-side credentials.

The function uses NEXT_PUBLIC_SUPABASE_PUBLISHABLE_DEFAULT_KEY (the anon/public key) to validate JWT tokens via supabase.auth.getUser(). The anon key is designed to be public and cannot properly validate tokens server-side. Token validation should use the service role key to ensure proper verification.

Authentication error messages from Supabase are logged via console.warn. These error messages may contain sensitive information about why authentication failed.

**Perspective 1:** The `getUserFromRequest` function uses `NEXT_PUBLIC_SUPABASE_PUBLISHABLE_DEFAULT_KEY` (the public anon key) to verify JWT tokens. This key is designed for client-side use and cannot securely verify tokens server-side. The function claims to validate authentication but uses the wrong key, making the validation ineffective. The server-side `supabase-server.ts` correctly uses `SUPABASE_SECRET_KEY` for the same purpose. **Perspective 2:** The authentication validation uses the public anon key instead of the service role key. This means that the validation is not secure and can be bypassed by anyone with access to the public key.

**Perspective 1:** The frontend `downloadFile` function fetches objects from Cloudflare R2 but does not verify the integrity of the downloaded data. This is a duplicate of the backend issue but in a separate codebase, meaning both client and server are vulnerable to serving tampered files. **Perspective 2:** The frontend storage module downloads files from R2 object storage without verifying their integrity via checksums. This could allow corrupted or tampered files to be served to users. **Perspective 3:** The frontend storage module mirrors the backend's R2 operations but lacks artifact signing. This is a duplicate concern in a separate codebase, meaning both client and server-side document handling lack cryptographic provenance verification.

The frontend/src/lib/storage.ts file contains client-side R2 storage utilities that use @aws-sdk/client-s3 with credentials from environment variables. If these environment variables are exposed to the browser (via NEXT_PUBLIC_* prefix), the R2 access key and secret would be visible to all users, allowing direct access to the R2 bucket. The file imports S3Client and uses credentials directly, which is a significant security risk if these are client-side accessible.

**Perspective 1:** The getSignedUrl function in the frontend code would allow client-side generation of presigned URLs if the credentials were accessible. Since the credentials are exposed in the frontend, an attacker could generate presigned URLs for any R2 object, potentially accessing or exfiltrating all documents in the bucket. **Perspective 2:** The ability to generate presigned URLs is exposed in client-side code. This means users can potentially generate URLs for any document in the S3 bucket, bypassing server-side access controls. Presigned URL generation should only happen on the server side. **Perspective 3:** The getSignedUrl function in the frontend code would allow generation of presigned URLs using exposed credentials. Since the R2 credentials are accessible in the browser, an attacker could generate presigned URLs with arbitrary expiration times, potentially creating permanent access tokens to documents.

The file 'supabase-server.ts' is located in the frontend source directory and imports createClient from supabase-js. If this file is bundled and sent to the browser, the SUPABASE_SECRET_KEY (service role key) would be exposed to all users, granting full database access.

**Perspective 1:** In backend/src/lib/downloadTokens.ts, the getSecret() function falls back to 'dev-secret' if DOWNLOAD_SIGNING_SECRET and SUPABASE_SECRET_KEY are not set. This is a weak, hardcoded secret that could be exploited in production if environment variables are misconfigured. **Perspective 2:** The frontend file frontend/src/lib/supabase-server.ts imports SUPABASE_SECRET_KEY (the service role key) from environment variables. If this file is bundled into the client-side JavaScript, the service role key would be exposed to all users, granting full database access.

**Perspective 1:** When SUPABASE_URL or SUPABASE_SECRET_KEY are not set, the function returns the raw token string as the user ID. This bypasses all authentication and could allow token injection attacks in development environments that accidentally reach production-like data. **Perspective 2:** The createServerSupabase function uses SUPABASE_SECRET_KEY (service role key) in frontend code. If this is actually used client-side, it exposes the service role key which bypasses all RLS policies and grants full database access.

The `createServerSupabase` function creates a Supabase client with the service role key, which bypasses Row-Level Security (RLS). If this client is used in contexts where the user's permissions should be enforced, it could lead to unauthorized data access.

The createServerSupabase function creates a Supabase client with the service role key, which bypasses Row-Level Security (RLS). Any queries made with this client must manually filter by tenant/user context. If any query using this client omits a tenant_id filter, it could return data from all tenants.

The `getUserIdFromRequest` function has a dev fallback that accepts the raw token as the user ID when Supabase credentials are not configured. This bypasses all authentication and allows arbitrary user impersonation.

The `getUserIdFromRequest` function has a dev fallback that accepts the raw token as user ID if Supabase URL or service key is missing. In production, if these environment variables are misconfigured, an attacker could impersonate any user by providing an arbitrary token.

The createServerSupabase function uses SUPABASE_SECRET_KEY (service role key) in a frontend file (src/lib/supabase-server.ts). This key bypasses Row Level Security and should never be exposed to the client. If this file is bundled with the frontend, the key is exposed.

The SUPABASE_SECRET_KEY (service role key) is imported in a file that could potentially be bundled with client-side code. Service role keys bypass Row Level Security and should never be exposed to clients.

The `createServerSupabase` function creates a Supabase client with the service role key (`SUPABASE_SECRET_KEY`). This key bypasses Row-Level Security (RLS). If this function is imported and used in a client component or exposed to the browser, the service role key would be compromised.

When SUPABASE_SECRET_KEY is not set, the function falls back to accepting the raw token string as the user ID. This bypasses all authentication and allows arbitrary user impersonation in development environments.

The file imports SUPABASE_SECRET_KEY (the service role key) in frontend code. If this file is bundled and served to the browser, the service role key will be exposed to all users, granting full database access without RLS restrictions.

In the `getUserIdFromRequest` function, if `SUPABASE_URL` or `SUPABASE_SECRET_KEY` are not set, the function returns the raw token from the Authorization header as the user ID. This means any string can be used to impersonate any user in development, and if this code path is accidentally reached in production, it bypasses authentication entirely.

**Perspective 1:** When `SUPABASE_SECRET_KEY` is not set, the `getUserIdFromRequest` function returns the raw token string as the user ID without any verification. This means in development or misconfigured environments, any string passed as a Bearer token is accepted as a valid user ID, completely bypassing authentication. **Perspective 2:** The development fallback bypasses JWT verification entirely, meaning that in development mode, any token is accepted. This is a security risk if the development environment is exposed to the network.

When SUPABASE_SECRET_KEY is not set, the function returns the raw Bearer token as the user ID without any validation. This means any token string is accepted as a valid user ID, completely bypassing authentication. This is a dangerous dev fallback that could be accidentally deployed.

**Perspective 1:** When SUPABASE_SECRET_KEY is not set, the function falls back to accepting the raw Bearer token as the user ID. This bypasses all JWT validation, allowing any string to impersonate any user in development environments. If this code path is accidentally used in production, it completely breaks authentication. **Perspective 2:** In development mode, the code accepts a raw token string as the user ID without any cryptographic verification. This completely bypasses authentication and allows any request with a non-empty token to impersonate any user.

In development mode, the `getUserIdFromRequest` function accepts a raw token as the user ID without any verification. This bypasses authentication entirely and could allow an attacker to impersonate any user.

When SUPABASE_URL or SUPABASE_SECRET_KEY are not set, the function returns the raw Bearer token as the user ID without any validation. This means any string passed as a token will be accepted as a valid user ID in development, and if this code path is ever hit in production due to misconfiguration, authentication is completely bypassed.

**Perspective 1:** When Supabase URL or service key is missing, the function falls back to accepting the raw token string as the user ID. This bypasses all authentication in development environments and could be accidentally deployed. **Perspective 2:** In development mode, the raw token string is used as the user ID, which could lead to authentication bypass if this code is accidentally used in production.

The Supabase anon key (`NEXT_PUBLIC_SUPABASE_PUBLISHABLE_DEFAULT_KEY`) is exposed in the frontend code. While anon keys are meant to be public, the environment variable name suggests this might be a publishable/default key that should be restricted. The key is loaded from `NEXT_PUBLIC_SUPABASE_PUBLISHABLE_DEFAULT_KEY` which is accessible to anyone viewing the page source.

Cross-chunk interaction detected. This finding interacts with confirmed threat [26] via config. Interaction chain: LibreOffice installed in production image (385) provides the binary that the confirmed RCE vector (26) exploits via document conversion Original finding: **Perspective 1:** The nixpacks configuration installs LibreOffice as a Nix package. LibreOffice is a large dependency (hundreds of MB) that increases the attack surface and image size. If only needed for document conversion, consider a lighter alternative or ensure it runs in a separate ephemeral container. **Perspective 2:** LibreOffice is installed in the production container image. This large dependency increases the attack surface and image size unnecessarily. If document conversion is nee

Cross-chunk interaction detected. This finding interacts with confirmed threat [32] via config. Interaction chain: Server version header disclosure (386) combined with permissive CORS (32) provides attackers with stack fingerprinting to target known Express vulnerabilities Original finding: Express.js by default exposes the 'X-Powered-By: Express' header in all responses, revealing the server technology to attackers. This helps attackers fingerprint the application stack.

Cross-chunk interaction detected. This finding interacts with confirmed threat [32] via config. Interaction chain: Unpinned Express dependency (388) combined with permissive CORS (32) allows attackers to exploit known Express CVEs against a vulnerable version Original finding: The express and cors packages are imported but their versions are not pinned in the visible code. Express has had multiple CVEs (e.g., CVE-2024-29041 for path traversal, CVE-2023-32695 for XSS). Unpinned versions may introduce known vulnerabilities.

Cross-chunk interaction detected. This finding interacts with confirmed threat [32] via config. Interaction chain: Single-origin CORS without tenant awareness (389) combined with permissive CORS (32) enables cross-tenant data access via token forgery Original finding: The CORS configuration allows a single origin (FRONTEND_URL or localhost:3000). While this is not a direct tenant isolation issue, the backend does not appear to have tenant-aware CORS policies. If the frontend serves multiple tenants from different subdomains, the CORS configuration would need to be dynamic.

Cross-chunk interaction detected. This finding interacts with confirmed threat [32] via config. Interaction chain: CORS allows localhost subdomains (390) combined with permissive CORS (32) enables local network attacks to bypass origin restrictions Original finding: **Perspective 1:** CORS is configured with origin: process.env.FRONTEND_URL ?? 'http://localhost:3000'. If FRONTEND_URL is not set, it defaults to localhost:3000. However, the CORS configuration does not validate the Host header, leaving the application potentially vulnerable to Host header injection attacks if deployed behind a reverse proxy that doesn't validate the Host header. **Perspective 2:** The application has no rate limiting middleware. This exposes authentication endpoints, chat end

Cross-chunk interaction detected. This finding interacts with confirmed threat [30] via config. Interaction chain: Unlimited request body size (391) combined with no rate limiting (30) enables large payload DoS attacks against the backend Original finding: Express JSON body parser is configured with a 50MB limit, which is very large and could allow denial-of-service attacks through oversized payloads.

Cross-chunk interaction detected. This finding interacts with confirmed threat [32] via config. Interaction chain: Missing security headers (392) combined with permissive CORS (32) allows clickjacking and XSS attacks against authenticated users Original finding: **Perspective 1:** The Express application does not set security headers such as Helmet middleware. Missing headers include: Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security, and others. **Perspective 2:** The application does not implement rate limiting on any routes, making it vulnerable to brute-force attacks, denial-of-service, and API abuse.

Cross-chunk interaction detected. This finding interacts with confirmed threat [37] via data_flow. Interaction chain: Email-based access control without privacy safeguards (393) combined with missing authorization for documents without project_id (37) enables unauthorized document access via email enumeration Original finding: **Perspective 1:** The access control system uses email addresses (shared_with field) to determine project access. Email addresses are stored in plaintext in the shared_with array. There is no mechanism for users to control what email addresses are used for sharing, no consent for sharing their email, and no way for users to see who has shared projects with them. **Perspective 2:** Project sharing records (shared_with email addresses) have no defined retention period. When a project is deleted

Cross-chunk interaction detected. This finding interacts with confirmed threat [37] via data_flow. Interaction chain: Email case sensitivity issues in shared_with check (394) combined with missing authorization (37) allows access bypass through email casing variations Original finding: The checkProjectAccess function compares user emails case-insensitively by converting both to lowercase. However, the shared_with array in the database may contain emails with different casing. While the comparison is case-insensitive, the initial storage of emails should also be normalized to prevent duplicates.

Cross-chunk interaction detected. This finding interacts with confirmed threat [37] via call. Interaction chain: Potential SQL injection in listAccessibleProjectIds (395) combined with missing authorization (37) enables database query manipulation to access unauthorized documents Original finding: The listAccessibleProjectIds function uses the contains filter with userEmail directly. While Supabase's query builder parameterizes queries, the use of userEmail without validation could potentially lead to issues if the email contains special characters.

Cross-chunk interaction detected. This finding interacts with confirmed threat [37] via call. Interaction chain: Injection via user email in Supabase query (396) combined with missing authorization (37) allows database injection through email parameter to access unauthorized documents Original finding: The `listAccessibleProjectIds` function passes `userEmail` directly into a Supabase `.contains()` filter. If `userEmail` contains special characters (e.g., quotes, brackets), it could be interpreted as part of the query syntax rather than a literal value. While Supabase's client SDK provides some protection, the `.contains()` method for JSONB arrays may not fully escape string values.

Cross-chunk interaction detected. This finding interacts with confirmed threat [8] via data_flow. Interaction chain: Predictable storage path pattern for document edits (397) combined with version history enumeration (8) enables attackers to enumerate and access all document versions Original finding: The storage path for edited document versions follows a predictable pattern: 'documents/{userId}/{documentId}/edits/{versionId}.docx'. While the versionId is random, the path structure leaks user IDs and document IDs, and the versionId is the only source of uniqueness. An attacker who can enumerate version IDs could potentially access document versions.

Cross-chunk interaction detected. This finding interacts with confirmed threat [38] via data_flow. Interaction chain: Generated DOCX documents lack provenance metadata (398) combined with model response used without integrity verification (38) enables undetected document tampering Original finding: **Perspective 1:** The generate_docx function creates Word documents without embedding provenance metadata such as the model version, generation timestamp, or a hash of the input prompt. This makes it impossible to verify the origin of generated documents or detect if they have been tampered with after generation. **Perspective 2:** The chat tools module references model providers (Gemini, Claude) without storing or verifying provenance metadata about the model artifacts. There is no mechanism

Cross-chunk interaction detected. This finding interacts with confirmed threat [38] via data_flow. Interaction chain: Error messages from generateDocx leaked to client (399) combined with model response without integrity verification (38) exposes internal paths and stack traces to attackers Original finding: **Perspective 1:** The generateDocx function catches exceptions and returns { error: String(e) }. This stringifies the entire error object, which may include stack traces, internal paths, or other sensitive information that gets sent back to the client. **Perspective 2:** When inserting the document or version row fails, the error message from the database (e.g., constraint violation details) is returned directly to the client in the error field.

Cross-chunk interaction detected. This finding interacts with confirmed threat [26] via config. Interaction chain: Unverified LibreOffice binary dependency (400) combined with confirmed RCE vector (26) enables supply chain attacks through compromised LibreOffice installation Original finding: The project relies on LibreOffice (via libreoffice-convert) for DOCX-to-PDF conversion. There is no verification of the LibreOffice binary's integrity or provenance. If the system's LibreOffice installation is compromised, all document conversions could be tampered with.

Cross-chunk interaction detected. This finding interacts with confirmed threat [26] via data_flow. Interaction chain: Zip bomb vulnerability in DOCX normalization (401) combined with LibreOffice RCE (26) enables memory exhaustion attacks during document conversion Original finding: The normalizeDocxZipPaths function loads the entire DOCX file into memory using JSZip. A maliciously crafted zip bomb (highly compressed file that expands to a large size) could cause memory exhaustion during decompression. JSZip does not have built-in protection against zip bombs.

Cross-chunk interaction detected. This finding interacts with confirmed threat [26] via data_flow. Interaction chain: Unsafe ZIP path normalization (402) combined with LibreOffice RCE (26) enables path traversal attacks during document processing Original finding: The `normalizeDocxZipPaths` function processes ZIP entries with backslash separators but does not validate that the resulting paths are within the expected directory structure. A malicious DOCX file could contain entries with path traversal sequences.

Cross-chunk interaction detected. This finding interacts with confirmed threat [26] via data_flow. Interaction chain: Zip path traversal via backslash normalization (403) combined with LibreOffice RCE (26) enables arbitrary file write during document conversion Original finding: The normalizeDocxZipPaths function renames zip entries with backslashes to forward slashes. If a malicious zip file contains entries with path traversal sequences (e.g., '../' or absolute paths), the normalization could allow overwriting files outside the intended extraction directory. While the function only renames entries and doesn't extract files, downstream consumers might be affected.

Cross-chunk interaction detected. This finding interacts with confirmed threat [8] via data_flow. Interaction chain: Document version storage paths lack integrity verification (404) combined with version history enumeration (8) enables attackers to access tampered document versions Original finding: Document version storage paths are retrieved from the database and used to download files without verifying the integrity of the stored paths or the downloaded content. A compromised database could redirect downloads to malicious content.

Cross-chunk interaction detected. This finding interacts with confirmed threat [26] via data_flow. Interaction chain: Potential deserialization via JSON.parse in citation parsing (405) combined with LibreOffice RCE (26) enables code execution through crafted DOCX citations Original finding: The parseTabularCitations function uses JSON.parse on user-controlled text extracted from DOCX files. While JSON.parse itself is safe, the parsed data is used in subsequent operations without validation, potentially leading to prototype pollution if the parsed object contains __proto__ or constructor keys.

Cross-chunk interaction detected. This finding interacts with confirmed threat [26] via data_flow. Interaction chain: Potential injection via DOCX tracked changes XML (406) combined with LibreOffice RCE (26) enables XML injection attacks during document processing Original finding: **Perspective 1:** The reconstructParagraph function builds XML elements from user-controlled text content. While the XML builder escapes text content, the element names and attribute values are hardcoded. However, the text content could contain XML special characters that might break the XML structure if not properly escaped. **Perspective 2:** The findUniqueAnchor function uses string matching on user-controlled text. While not directly vulnerable to regex injection (no RegExp constructor use

Cross-chunk interaction detected. This finding interacts with confirmed threat [26] via data_flow. Interaction chain: DOCX XML parser without entity expansion protection (407) combined with LibreOffice RCE (26) enables billion laughs DoS attack during document conversion Original finding: The fast-xml-parser is used to parse DOCX XML content without explicit protection against XML entity expansion attacks (billion laughs attack). Malicious DOCX files could cause denial of service or memory exhaustion.

Cross-chunk interaction detected. This finding interacts with confirmed threat [0] via config. Interaction chain: Download token signing uses fallback secret (408) combined with weak default signing secret (0) enables token forgery for any file download Original finding: The download token signing secret falls back to 'dev-secret' if DOWNLOAD_SIGNING_SECRET and SUPABASE_SECRET_KEY are not set. This makes tokens predictable and forgeable in production deployments with missing environment variables.

Cross-chunk interaction detected. This finding interacts with confirmed threat [0] via config. Interaction chain: Download token uses weak default secret (409) combined with weak default signing secret (0) enables attackers to forge valid download tokens Original finding: The download signing secret falls back to `"dev-secret"` if `DOWNLOAD_SIGNING_SECRET` and `SUPABASE_SECRET_KEY` are not set. This allows an attacker to forge download tokens for any file.

Cross-chunk interaction detected. This finding interacts with confirmed threat [11] via data_flow. Interaction chain: Potential path traversal in download token verification (410) combined with forged token streaming (11) enables arbitrary file read on the server Original finding: The `verifyDownload` function decodes the token and extracts `path` and `filename`. If the path contains path traversal sequences (e.g., '../'), an attacker could access files outside the intended directory. The function does not validate the path against traversal attacks.

Cross-chunk interaction detected. This finding interacts with confirmed threat [1] via data_flow. Interaction chain: Non-expiring download tokens (411) combined with weak HMAC secret (1) enables permanent file access after token forgery Original finding: Download tokens are HMAC-signed but have no expiration mechanism. Tokens stored in chat history are valid indefinitely. If a token is leaked, the file can be downloaded at any time without time-bound protection.

Cross-chunk interaction detected. This finding interacts with confirmed threat [1] via data_flow. Interaction chain: Non-expiring download tokens (412) combined with weak HMAC secret (1) enables indefinite file access through forged tokens Original finding: **Perspective 1:** Download tokens are HMAC-signed but have no expiration mechanism. Once a token is generated (e.g., stored in chat history), it remains valid indefinitely. This increases the window of opportunity for token theft or replay attacks. **Perspective 2:** The buildDownloadUrl function creates tokens with no expiration timestamp. This means a leaked or intercepted download URL can be used indefinitely to access the document. Tokens should include an expiration claim (e.g., exp in JW

Cross-chunk interaction detected. This finding interacts with confirmed threat [1] via data_flow. Interaction chain: Timing-safe comparison uses string length check (413) combined with weak HMAC secret (1) enables timing attacks to brute-force download tokens Original finding: The timingSafeEqStr function checks string lengths before calling crypto.timingSafeEqual. While this doesn't leak timing for equal-length strings, the early return on length mismatch could theoretically leak the token length. More importantly, the function is only used for signature verification, but the length check pattern is non-standard.

Cross-chunk interaction detected. This finding interacts with confirmed threat [1] via data_flow. Interaction chain: Download tokens never expire (414) combined with weak HMAC secret (1) enables permanent unauthorized file access Original finding: The `signDownload` function creates tokens with no expiration timestamp. Once issued, a token remains valid indefinitely, even if the underlying file should no longer be accessible (e.g., user removed from project, document deleted).

Cross-chunk interaction detected. This finding interacts with confirmed threat [38] via data_flow. Interaction chain: Raw streaming data logged to filesystem without sanitization (415) combined with model response without integrity verification (38) exposes sensitive model outputs in logs Original finding: The Claude raw stream events are logged to a file (claude-raw-stream.log) via console.log and fs.appendFile. This could expose sensitive model outputs, API keys, or user data to the filesystem without proper access controls or sanitization.

Cross-chunk interaction detected. This finding interacts with confirmed threat [38] via call. Interaction chain: Model name passed without allowlist validation (416) combined with model response without integrity verification (38) enables attackers to specify arbitrary models Original finding: The Claude streaming function accepts a model parameter that is passed directly to the Anthropic SDK without validation against an allowlist. An attacker who can control the model parameter could potentially redirect requests to a different model endpoint.

Cross-chunk interaction detected. This finding interacts with confirmed threat [38] via data_flow. Interaction chain: API key passed as parameter in streamClaude (417) combined with model response without integrity verification (38) enables API key exposure through model responses Original finding: The `streamClaude` function receives `apiKeys` as a parameter and passes it to the `client` function. If this function is called from multiple places, the API key could be logged or exposed through stack traces if errors occur.

Cross-chunk interaction detected. This finding interacts with confirmed threat [2] via data_flow. Interaction chain: Full Gemini stream chunks logged to console (418) combined with no token budget enforcement (2) exposes user data and document content in logs Original finding: The Gemini streaming function logs every chunk from the API response, which may contain user messages, document content, or other PII that was sent to the LLM.

Cross-chunk interaction detected. This finding interacts with confirmed threat [2] via config. Interaction chain: Unpinned @google/genai dependency (419) combined with no token budget enforcement (2) enables supply chain attacks that increase token consumption Original finding: The @google/genai package is imported but its version is not pinned in the visible code. This could lead to unexpected breaking changes or security vulnerabilities if a malicious version is published.

Cross-chunk interaction detected. This finding interacts with confirmed threat [2] via config. Interaction chain: API key fallback to empty string (420) combined with no token budget enforcement (2) causes silent authentication failures that waste resources Original finding: When GEMINI_API_KEY environment variable is not set and no override is provided, the function falls back to an empty string. This will cause the Google GenAI client to fail with an authentication error, but the error message may leak the empty key or cause confusing failures.

Cross-chunk interaction detected. This finding interacts with confirmed threat [2] via call. Interaction chain: Model name passed directly from user input without allowlisting (421) combined with no token budget enforcement (2) enables attackers to use expensive models Original finding: The `model` parameter in `streamGemini` is passed directly from the request without validation against an allowlist. A user could specify an arbitrary model name, potentially accessing restricted or unintended models.

Cross-chunk interaction detected. This finding interacts with confirmed threat [2] via data_flow. Interaction chain: API key passed without proper validation (422) combined with no token budget enforcement (2) enables unauthorized API key usage for token consumption Original finding: The Gemini API key is passed directly from environment variables or user-provided apiKeys. There is no validation that the key is scoped to the minimum required permissions or that it hasn't been revoked.

Cross-chunk interaction detected. This finding interacts with confirmed threat [38] via data_flow. Interaction chain: No integrity verification for model responses (423) combined with model response without integrity verification (38) enables response manipulation attacks Original finding: The streaming response from the Gemini API is consumed without any integrity checks (e.g., HMAC, digital signature). A compromised or intercepted API response could inject malicious content or tool calls.

Cross-chunk interaction detected. This finding interacts with confirmed threat [2] via data_flow. Interaction chain: Sensitive data logged in console (424) combined with no token budget enforcement (2) exposes API keys and user data in Gemini stream logs Original finding: The entire Gemini stream chunk is logged to console via `JSON.stringify(chunk, null, 2)`. This may include sensitive information such as API keys, user data, or internal system details in the response.

Cross-chunk interaction detected. This finding interacts with confirmed threat [38] via data_flow. Interaction chain: Model response used without output validation (425) combined with model response without integrity verification (38) enables injection of malicious content from compromised models Original finding: The `completeGeminiText` function returns the model's text output directly without any validation or sanitization. A compromised model could return malicious content that is then used in downstream operations.

Cross-chunk interaction detected. This finding interacts with confirmed threat [38] via config. Interaction chain: No TLS enforcement for LLM API communication (426) combined with model response without integrity verification (38) enables MITM attacks on model responses Original finding: **Perspective 1:** The streamChatWithTools and completeText functions delegate to provider-specific implementations (streamClaude, streamGemini) but there is no explicit enforcement of TLS or certificate validation for the underlying HTTP connections to Anthropic and Google APIs. If the underlying HTTP client does not enforce TLS, API keys and prompt data could be intercepted. **Perspective 2:** The LLM client library does not enforce TLS certificate validation or specify minimum TLS version wh

Cross-chunk interaction detected. This finding interacts with confirmed threat [2] via config. Interaction chain: Unpinned @google/genai dependency (427) combined with no token budget enforcement (2) enables supply chain attacks that increase token consumption Original finding: The gemini module imports @google/genai without a pinned version, introducing supply chain risk from future updates.

Cross-chunk interaction detected. This finding interacts with confirmed threat [38] via data_flow. Interaction chain: No encryption for LLM API keys (428) combined with model response without integrity verification (38) enables API key theft through model response manipulation Original finding: **Perspective 1:** The code defines model IDs and provider inference but does not show any encryption or secure handling of API keys used to authenticate with LLM providers (Anthropic, Google). API keys are passed as plain strings via UserApiKeys type. If these keys are transmitted or stored without encryption, they could be exposed to interception or unauthorized access. **Perspective 2:** The codebase does not enforce TLS or any form of encryption when transmitting LLM API keys (Claude, Gemin

Cross-chunk interaction detected. This finding interacts with confirmed threat [38] via data_flow. Interaction chain: Model configuration without provenance metadata (429) combined with model response without integrity verification (38) enables undetected model substitution attacks Original finding: The model configuration file defines canonical model IDs and their providers but does not include any provenance metadata such as model version hashes, training data hashes, or license information. This makes it impossible to verify the integrity or origin of the model artifacts being used.

Cross-chunk interaction detected. This finding interacts with confirmed threat [38] via data_flow. Interaction chain: No integrity verification for LLM provider tool schemas (430) combined with model response without integrity verification (38) enables tool call injection attacks Original finding: **Perspective 1:** The tool schema adapters (`toClaudeTools`, `toGeminiTools`) transform OpenAI-style tool definitions for different LLM providers but perform no validation or integrity checks on the schema inputs. A compromised or malicious schema could inject unexpected tool definitions that lead to unintended model behavior. **Perspective 2:** The tools module (referenced in chatTools.ts) defines tool schemas for LLM providers, but there is no integrity verification (e.g., checksum or signat

Cross-chunk interaction detected. This finding interacts with confirmed threat [38] via data_flow. Interaction chain: Model provider types without provenance metadata (431) combined with model response without integrity verification (38) enables undetected model provider substitution Original finding: The LLM provider types (Provider, StreamChatParams) define the interface for model interactions but include no fields for model version, commit hash, checksum, or any provenance metadata. This means the application has no mechanism to verify that the model being used is the intended one, or to detect if a model has been swapped or tampered with.

Cross-chunk interaction detected. This finding interacts with confirmed threat [10] via call. Interaction chain: Presigned URL generation without access control validation (432) combined with missing tenant membership verification (10) enables unauthorized file downloads Original finding: **Perspective 1:** The getSignedUrl function generates presigned URLs for R2 objects but does not validate whether the requesting user has permission to access the specific document. The function only checks if storage is enabled, not if the caller is authorized to access the key. This could allow unauthorized access to documents if the function is called without prior authorization checks. **Perspective 2:** Presigned URLs are generated without verifying that the requesting user has permission

Cross-chunk interaction detected. This finding interacts with confirmed threat [11] via data_flow. Interaction chain: Signed URL uses user-provided filename without full sanitization (433) combined with forged token streaming (11) enables Content-Disposition injection attacks Original finding: The getSignedUrl function accepts a downloadFilename parameter that is used to build the Content-Disposition header. While sanitizeDispositionFilename removes some characters, it may not handle all edge cases (e.g., unicode normalization, null bytes). An attacker could potentially inject headers or cause filename confusion.

Cross-chunk interaction detected. This finding interacts with confirmed threat [11] via data_flow. Interaction chain: Filename used in Content-Disposition without full sanitization (434) combined with forged token streaming (11) enables HTTP header injection during downloads Original finding: The `buildContentDisposition` function sanitizes the filename by removing control characters and backslashes, but does not fully encode or validate the filename for all edge cases. The `sanitizeDispositionFilename` function only replaces `"` and `\` with underscores, which may not be sufficient for all malicious filenames. Additionally, the `encodeRFC5987` function does not encode all special characters that could cause issues in HTTP headers.

Cross-chunk interaction detected. This finding interacts with confirmed threat [6] via call. Interaction chain: JWT verification uses admin client getUser instead of proper verification (435) combined with missing authorization on chat endpoint (6) enables token replay attacks Original finding: **Perspective 1:** The getUserIdFromRequest function extracts the Bearer token and calls admin.auth.getUser(token) to verify it. This approach makes an API call to Supabase for every request instead of locally verifying the JWT signature. While functional, it introduces a dependency on Supabase availability and doesn't validate the JWT structure, expiration, or signature locally. A more robust approach would be to verify the JWT locally using the Supabase JWT secret. **Perspective 2:** The code

Cross-chunk interaction detected. This finding interacts with confirmed threat [6] via config. Interaction chain: Service role key used for JWT verification (436) combined with missing authorization on chat endpoint (6) enables privilege escalation through service role key exposure Original finding: The getUserIdFromRequest function creates a new Supabase admin client with the service role key to verify JWT tokens. While this works, it creates an unnecessary admin client instance for every request. The service role key should be reserved for operations that need to bypass RLS, not for simple token verification.

Cross-chunk interaction detected. This finding interacts with confirmed threat [6] via data_flow. Interaction chain: Service role key used for JWT verification (437) combined with missing authorization on chat endpoint (6) enables unauthorized access to chat functionality Original finding: The `getUserIdFromRequest` function uses the service role key (`SUPABASE_SECRET_KEY`) to verify JWT tokens. This is a valid approach but the service role key is loaded from environment variables and could be exposed. Additionally, the function throws Response objects with error messages that reveal server configuration details.

Cross-chunk interaction detected. This finding interacts with confirmed threat [26] via data_flow. Interaction chain: File upload without file type validation (438) combined with LibreOffice RCE (26) enables malicious file uploads that trigger code execution during conversion Original finding: **Perspective 1:** The multer upload configuration accepts any file type without server-side validation of the actual file content. The accept attribute in the frontend is client-side only and can be bypassed. An attacker could upload executable files or other dangerous content. **Perspective 2:** The `singleFileUpload` function uses multer for file uploads but does not validate file content type or magic bytes. An attacker could upload a malicious file (e.g., a DOCX with embedded malware) that

Cross-chunk interaction detected. This finding interacts with confirmed threat [26] via data_flow. Interaction chain: File upload handler does not validate file content type (439) combined with LibreOffice RCE (26) enables upload of crafted files that exploit conversion vulnerabilities Original finding: The multer upload handler accepts files with any extension and does not validate the actual file content against the declared MIME type. A malicious user could upload a file with a benign extension but malicious content.

Cross-chunk interaction detected. This finding interacts with confirmed threat [26] via config. Interaction chain: Unpinned multer dependency (440) combined with LibreOffice RCE (26) enables exploitation of known multer vulnerabilities during file upload Original finding: The multer package is imported but its version is not pinned in the visible code. Multer has had past vulnerabilities (e.g., CVE-2022-24434 for denial of service). An unpinned version may introduce known CVEs.

Cross-chunk interaction detected. This finding interacts with confirmed threat [30] via data_flow. Interaction chain: No per-user storage quota enforcement (441) combined with no rate limiting (30) enables storage exhaustion attacks through unlimited uploads Original finding: The upload handler has a 100MB per-file limit but no per-user storage quota. An attacker could upload many files, each up to 100MB, consuming cloud storage and bandwidth. Storage costs scale linearly with upload volume.

Cross-chunk interaction detected. This finding interacts with confirmed threat [10] via data_flow. Interaction chain: File upload handler does not enforce tenant-specific storage paths (442) combined with missing tenant membership verification (10) enables cross-tenant file access Original finding: The multer-based upload handler stores files in memory but does not enforce tenant-specific storage paths. The actual storage path is determined by the calling route handler. If any route handler uses a predictable or non-tenant-scoped storage path, files from different tenants could overwrite or be accessible to each other.

Cross-chunk interaction detected. This finding interacts with confirmed threat [30] via config. Interaction chain: Large maximum upload size (443) combined with no rate limiting (30) enables disk space exhaustion through large file uploads Original finding: Maximum upload size is set to 100MB, which is very large and could allow disk space exhaustion attacks.

Cross-chunk interaction detected. This finding interacts with confirmed threat [26] via data_flow. Interaction chain: No file type validation on upload (444) combined with LibreOffice RCE (26) enables arbitrary file upload that triggers code execution during conversion Original finding: Multer is configured without file filter validation, allowing any file type to be uploaded. This could lead to malicious file uploads.

Cross-chunk interaction detected. This finding interacts with confirmed threat [30] via data_flow. Interaction chain: Multer file size limit only applies to single files (445) combined with no rate limiting (30) enables bypass of size limits through concurrent uploads Original finding: The multer configuration limits file size to 100MB and files to 1, but there is no protection against multiple concurrent uploads or chunked uploads that could bypass the size limit.

Cross-chunk interaction detected. This finding interacts with confirmed threat [6] via data_flow. Interaction chain: Database error not caught in getUserModelSettings (446) combined with missing authorization on chat endpoint (6) enables error-based information disclosure Original finding: The .single() call on the Supabase query will throw if no row is found or if there's a database error. This unhandled rejection could crash the request or leak database error details to the caller.

Cross-chunk interaction detected. This finding interacts with confirmed threat [38] via data_flow. Interaction chain: Model resolution fallback may use unverified model (447) combined with model response without integrity verification (38) enables use of compromised default models Original finding: The resolveTitleModel function falls back to DEFAULT_TITLE_MODEL when no user API keys are set. If the default model configuration is compromised or points to an untrusted model, all title generation requests would use the compromised model without any verification.

Cross-chunk interaction detected. This finding interacts with confirmed threat [6] via data_flow. Interaction chain: Database error not caught in getUserApiKeys (448) combined with missing authorization on chat endpoint (6) enables error-based information disclosure of API keys Original finding: Same issue as getUserModelSettings — the .single() call can throw, leading to an unhandled rejection or error leak.

Cross-chunk interaction detected. This finding interacts with confirmed threat [6] via config. Interaction chain: No build provenance in auth middleware (449) combined with missing authorization on chat endpoint (6) enables deployment of tampered authentication code Original finding: The auth middleware uses Supabase for authentication, but there is no build provenance or artifact signing for the backend code itself. Without signing, there is no way to verify the integrity or origin of the deployed backend artifacts.

Cross-chunk interaction detected. This finding interacts with confirmed threat [6] via data_flow. Interaction chain: User email stored in res.locals without encryption (450) combined with missing authorization on chat endpoint (6) enables email exposure through unauthorized chat access Original finding: The auth middleware stores the user's email in res.locals.userEmail in plaintext. This email is then accessible to all downstream middleware and route handlers. If any handler logs res.locals or includes it in error messages, the email is exposed.

Cross-chunk interaction detected. This finding interacts with confirmed threat [6] via data_flow. Interaction chain: Authentication error messages reveal failure reason (451) combined with missing authorization on chat endpoint (6) enables attackers to enumerate valid tokens Original finding: The auth middleware returns distinct error messages for missing/invalid Authorization header ('Missing or invalid Authorization header'), invalid/expired tokens ('Invalid or expired token'), and server misconfiguration ('Server auth is not configured'). These different messages allow an attacker to distinguish between different failure modes, aiding in fingerprinting the authentication mechanism and potentially enumerating valid vs. invalid token formats.

Cross-chunk interaction detected. This finding interacts with confirmed threat [6] via data_flow. Interaction chain: Token extraction without proper trimming (452) combined with missing authorization on chat endpoint (6) enables token manipulation attacks Original finding: The token is extracted by slicing 7 characters from the Authorization header and trimming. This could potentially accept malformed tokens if the header contains extra whitespace or unexpected characters. While the trim() call handles some cases, it doesn't validate the token format before passing it to the Supabase client.

Cross-chunk interaction detected. This finding interacts with confirmed threat [6] via data_flow. Interaction chain: Unhandled promise rejection in auth middleware (453) combined with missing authorization on chat endpoint (6) enables DoS through auth failures Original finding: The admin.auth.getUser(token) call is not wrapped in a try/catch. If the Supabase client throws (network error, timeout), the promise rejection will be unhandled, potentially crashing the process or leaking error details in the response.

Cross-chunk interaction detected. This finding interacts with confirmed threat [6] via data_flow. Interaction chain: Email normalization without validation (454) combined with missing authorization on chat endpoint (6) enables email-based authorization bypass Original finding: The email is lowercased with toLowerCase() but there's no validation that the email format is correct. This could lead to issues with email-based authorization checks if malformed email addresses are stored or used in comparisons.

Cross-chunk interaction detected. This finding interacts with confirmed threat [5] via data_flow. Interaction chain: No rate limiting on chat endpoint (455) combined with unbounded LLM token generation (5) enables unlimited token consumption through automated requests Original finding: The POST /chat streaming endpoint has no rate limiting. A user could script thousands of chat requests to exhaust the system's LLM API quota or incur excessive costs. The credit system in UserProfileContext is client-side only and not enforced server-side.

Cross-chunk interaction detected. This finding interacts with confirmed threat [5] via data_flow. Interaction chain: No rate limiting on chat streaming endpoint (456) combined with unbounded LLM token generation (5) enables token budget exploitation through long messages Original finding: **Perspective 1:** The POST /chat endpoint has no rate limiting, allowing an attacker to submit unlimited requests. This enables token budget exploitation — an attacker can send extremely long messages or high volumes of requests to maximize API costs. Combined with prompt injection, this could be used for denial-of-wallet attacks against the LLM provider. **Perspective 2:** The `runLLMStream` function in chatTools likely implements a tool-calling loop where the LLM can invoke tools, get result

Cross-chunk interaction detected. This finding interacts with confirmed threat [5] via data_flow. Interaction chain: Sensitive data in console.error for debugging (457) combined with unbounded LLM token generation (5) exposes error details during token exhaustion attacks Original finding: The generate-title endpoint logs errors to console.error with the error object. This could expose sensitive information about the failure.

Cross-chunk interaction detected. This finding interacts with confirmed threat [5] via data_flow. Interaction chain: Title generation errors logged to console (458) combined with unbounded LLM token generation (5) exposes message content in logs during title generation failures Original finding: The generate-title endpoint logs errors to console.error when title generation fails. This could expose information about the user's message content or the chat being processed.

Cross-chunk interaction detected. This finding interacts with confirmed threat [5] via data_flow. Interaction chain: Sensitive data in console.log for debugging (459) combined with unbounded LLM token generation (5) exposes user IDs and chat details in production logs Original finding: The chat stream endpoint logs incoming request details including userId, chat_id, project_id, model, and message count to the console. While not exposing message content, this logs internal identifiers that could be useful for an attacker.

Cross-chunk interaction detected. This finding interacts with confirmed threat [5] via data_flow. Interaction chain: User ID and chat details logged to console (460) combined with unbounded LLM token generation (5) exposes user activity patterns in centralized logging Original finding: The chat streaming endpoint logs user IDs, chat IDs, project IDs, and message counts to the console. In production environments with centralized logging, this could expose user activity patterns and internal identifiers.

Cross-chunk interaction detected. This finding interacts with confirmed threat [5] via data_flow. Interaction chain: Resolved chatId logged to console (461) combined with unbounded LLM token generation (5) exposes internal chat identifiers in production logs Original finding: The chat stream endpoint logs 'resolved chatId' to the console. This exposes internal chat identifiers in production logs.

Cross-chunk interaction detected. This finding interacts with confirmed threat [5] via data_flow. Interaction chain: Document and workflow metadata logged to console (462) combined with unbounded LLM token generation (5) exposes user document information in production logs Original finding: The chat streaming endpoint logs document counts, workflow counts, and API message counts to the console. This could expose information about the user's documents and workflows in production logs.

Cross-chunk interaction detected. This finding interacts with confirmed threat [5] via data_flow. Interaction chain: LLM stream start details logged to console (463) combined with unbounded LLM token generation (5) exposes internal state information during streaming Original finding: The chat stream endpoint logs LLM stream start details including apiMessageCount, docCount, and workflowCount to the console. This exposes internal state information.

Cross-chunk interaction detected. This finding interacts with confirmed threat [5] via data_flow. Interaction chain: LLM stream finished details logged to console (464) combined with unbounded LLM token generation (5) exposes internal state information after streaming Original finding: The chat stream endpoint logs LLM stream finished details including fullTextLen and eventCount to the console. This exposes internal state information.

The README instructs users to run 'npm install' without any mention of integrity verification. npm install by default does not verify package integrity against a lockfile unless 'package-lock.json' is present and trusted. The frontend has a package-lock.json, but the backend does not appear to have one (not shown in the diff). Without a lockfile or integrity verification, dependencies could be tampered with between releases.

**Perspective 1:** The nixpacks configuration installs LibreOffice as a Nix package. LibreOffice is a large dependency (hundreds of MB) that increases the attack surface and image size. If only needed for document conversion, consider a lighter alternative or ensure it runs in a separate ephemeral container. **Perspective 2:** LibreOffice is installed in the production container image. This large dependency increases the attack surface and image size unnecessarily. If document conversion is needed, it should be done in a separate service or sidecar container. **Perspective 3:** LibreOffice is installed in the production container image. This large dependency increases the attack surface and image size unnecessarily. If document conversion is needed, it should be done in a separate, dedicated service or at build time, not in the runtime container. **Perspective 4:** LibreOffice is installed in the production container image. This large dependency increases the attack surface and image size. If document conversion is needed, it should be isolated in a separate sidecar container or performed at build time.

Express.js by default exposes the 'X-Powered-By: Express' header in all responses, revealing the server technology to attackers. This helps attackers fingerprint the application stack.

The project does not implement any build provenance tracking (e.g., SLSA, in-toto attestations) or artifact signing. There is no mechanism to verify that the deployed backend or frontend artifacts were built from trusted source code and not tampered with during the build process.

The express and cors packages are imported but their versions are not pinned in the visible code. Express has had multiple CVEs (e.g., CVE-2024-29041 for path traversal, CVE-2023-32695 for XSS). Unpinned versions may introduce known vulnerabilities.

The CORS configuration allows a single origin (FRONTEND_URL or localhost:3000). While this is not a direct tenant isolation issue, the backend does not appear to have tenant-aware CORS policies. If the frontend serves multiple tenants from different subdomains, the CORS configuration would need to be dynamic.

**Perspective 1:** CORS is configured with origin: process.env.FRONTEND_URL ?? 'http://localhost:3000'. If FRONTEND_URL is not set, it defaults to localhost:3000. However, the CORS configuration does not validate the Host header, leaving the application potentially vulnerable to Host header injection attacks if deployed behind a reverse proxy that doesn't validate the Host header. **Perspective 2:** The application has no rate limiting middleware. This exposes authentication endpoints, chat endpoints, and other resources to brute-force attacks and abuse. Rate limiting should be enforced at the edge (reverse proxy) or application level. **Perspective 3:** The application does not have any request validation middleware (e.g., express-validator, Joi, or a custom schema validator) at the gateway level. This means malformed requests, unexpected content types, or injection attempts reach the route handlers without early rejection. **Perspective 4:** The CORS configuration allows any subdomain of localhost (e.g., malicious.localhost). While localhost is for development, this pattern can be exploited in SSRF scenarios or if the application is accidentally exposed. **Perspective 5:** The Express application does not set security headers like X-Content-Type-Options, X-Frame-Options, or Strict-Transport-Security. While this is an API server, these headers still provide defense-in-depth against certain attacks. **Perspective 6:** The application listens on plain HTTP. TLS termination should be handled at the reverse proxy/edge (e.g., nginx, Cloudflare, AWS ALB). This is acceptable if the edge handles TLS, but ensure no plaintext traffic flows between the proxy and backend in production. **Perspective 7:** The application does not implement IP-based access controls or allowlisting. For administrative endpoints or internal tools, IP-based restrictions at the edge can provide an additional layer of security.

Express JSON body parser is configured with a 50MB limit, which is very large and could allow denial-of-service attacks through oversized payloads.

**Perspective 1:** The Express application does not set security headers such as Helmet middleware. Missing headers include: Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security, and others. **Perspective 2:** The application does not implement rate limiting on any routes, making it vulnerable to brute-force attacks, denial-of-service, and API abuse.

**Perspective 1:** The access control system uses email addresses (shared_with field) to determine project access. Email addresses are stored in plaintext in the shared_with array. There is no mechanism for users to control what email addresses are used for sharing, no consent for sharing their email, and no way for users to see who has shared projects with them. **Perspective 2:** Project sharing records (shared_with email addresses) have no defined retention period. When a project is deleted or sharing is revoked, the email addresses may persist in the database. There is no mechanism to automatically purge old access control records. **Perspective 3:** Project sharing operations (adding/removing shared_with emails) have no audit logging. There is no record of who shared a project, with whom, when, or when access was revoked. This makes it difficult to detect unauthorized access or comply with data subject access requests.

The checkProjectAccess function compares user emails case-insensitively by converting both to lowercase. However, the shared_with array in the database may contain emails with different casing. While the comparison is case-insensitive, the initial storage of emails should also be normalized to prevent duplicates.

The listAccessibleProjectIds function uses the contains filter with userEmail directly. While Supabase's query builder parameterizes queries, the use of userEmail without validation could potentially lead to issues if the email contains special characters.

The `listAccessibleProjectIds` function passes `userEmail` directly into a Supabase `.contains()` filter. If `userEmail` contains special characters (e.g., quotes, brackets), it could be interpreted as part of the query syntax rather than a literal value. While Supabase's client SDK provides some protection, the `.contains()` method for JSONB arrays may not fully escape string values.

The storage path for edited document versions follows a predictable pattern: 'documents/{userId}/{documentId}/edits/{versionId}.docx'. While the versionId is random, the path structure leaks user IDs and document IDs, and the versionId is the only source of uniqueness. An attacker who can enumerate version IDs could potentially access document versions.

**Perspective 1:** The generate_docx function creates Word documents without embedding provenance metadata such as the model version, generation timestamp, or a hash of the input prompt. This makes it impossible to verify the origin of generated documents or detect if they have been tampered with after generation. **Perspective 2:** The chat tools module references model providers (Gemini, Claude) without storing or verifying provenance metadata about the model artifacts. There is no mechanism to verify that the model being used is the expected version or that it hasn't been replaced with a compromised variant. **Perspective 3:** The chat tools module selects model providers based on user settings without verifying the integrity of the provider configuration. A compromised configuration could redirect model requests to a malicious provider or use an untrusted model variant. **Perspective 4:** The tool schema adapters (TOOLS, PROJECT_EXTRA_TOOLS, TABULAR_TOOLS, WORKFLOW_TOOLS) are defined statically without integrity verification. While not directly loading model weights, these schemas define the interface between the model and the application, and a compromised schema could alter model behavior.

**Perspective 1:** The generateDocx function catches exceptions and returns { error: String(e) }. This stringifies the entire error object, which may include stack traces, internal paths, or other sensitive information that gets sent back to the client. **Perspective 2:** When inserting the document or version row fails, the error message from the database (e.g., constraint violation details) is returned directly to the client in the error field.

The project relies on LibreOffice (via libreoffice-convert) for DOCX-to-PDF conversion. There is no verification of the LibreOffice binary's integrity or provenance. If the system's LibreOffice installation is compromised, all document conversions could be tampered with.

The normalizeDocxZipPaths function loads the entire DOCX file into memory using JSZip. A maliciously crafted zip bomb (highly compressed file that expands to a large size) could cause memory exhaustion during decompression. JSZip does not have built-in protection against zip bombs.

The `normalizeDocxZipPaths` function processes ZIP entries with backslash separators but does not validate that the resulting paths are within the expected directory structure. A malicious DOCX file could contain entries with path traversal sequences.

The normalizeDocxZipPaths function renames zip entries with backslashes to forward slashes. If a malicious zip file contains entries with path traversal sequences (e.g., '../' or absolute paths), the normalization could allow overwriting files outside the intended extraction directory. While the function only renames entries and doesn't extract files, downstream consumers might be affected.

Document version storage paths are retrieved from the database and used to download files without verifying the integrity of the stored paths or the downloaded content. A compromised database could redirect downloads to malicious content.

The parseTabularCitations function uses JSON.parse on user-controlled text extracted from DOCX files. While JSON.parse itself is safe, the parsed data is used in subsequent operations without validation, potentially leading to prototype pollution if the parsed object contains __proto__ or constructor keys.

**Perspective 1:** The reconstructParagraph function builds XML elements from user-controlled text content. While the XML builder escapes text content, the element names and attribute values are hardcoded. However, the text content could contain XML special characters that might break the XML structure if not properly escaped. **Perspective 2:** The findUniqueAnchor function uses string matching on user-controlled text. While not directly vulnerable to regex injection (no RegExp constructor used), the normalization functions could be exploited with specially crafted Unicode strings to cause denial of service through excessive backtracking in the whitespace normalization.

The fast-xml-parser is used to parse DOCX XML content without explicit protection against XML entity expansion attacks (billion laughs attack). Malicious DOCX files could cause denial of service or memory exhaustion.

The download token signing secret falls back to 'dev-secret' if DOWNLOAD_SIGNING_SECRET and SUPABASE_SECRET_KEY are not set. This makes tokens predictable and forgeable in production deployments with missing environment variables.

The download signing secret falls back to `"dev-secret"` if `DOWNLOAD_SIGNING_SECRET` and `SUPABASE_SECRET_KEY` are not set. This allows an attacker to forge download tokens for any file.

The `verifyDownload` function decodes the token and extracts `path` and `filename`. If the path contains path traversal sequences (e.g., '../'), an attacker could access files outside the intended directory. The function does not validate the path against traversal attacks.

Download tokens are HMAC-signed but have no expiration mechanism. Tokens stored in chat history are valid indefinitely. If a token is leaked, the file can be downloaded at any time without time-bound protection.

**Perspective 1:** Download tokens are HMAC-signed but have no expiration mechanism. Once a token is generated (e.g., stored in chat history), it remains valid indefinitely. This increases the window of opportunity for token theft or replay attacks. **Perspective 2:** The buildDownloadUrl function creates tokens with no expiration timestamp. This means a leaked or intercepted download URL can be used indefinitely to access the document. Tokens should include an expiration claim (e.g., exp in JWT) to limit the window of exposure.

The timingSafeEqStr function checks string lengths before calling crypto.timingSafeEqual. While this doesn't leak timing for equal-length strings, the early return on length mismatch could theoretically leak the token length. More importantly, the function is only used for signature verification, but the length check pattern is non-standard.

The `signDownload` function creates tokens with no expiration timestamp. Once issued, a token remains valid indefinitely, even if the underlying file should no longer be accessible (e.g., user removed from project, document deleted).

The Claude raw stream events are logged to a file (claude-raw-stream.log) via console.log and fs.appendFile. This could expose sensitive model outputs, API keys, or user data to the filesystem without proper access controls or sanitization.

The Claude streaming function accepts a model parameter that is passed directly to the Anthropic SDK without validation against an allowlist. An attacker who can control the model parameter could potentially redirect requests to a different model endpoint.

The `streamClaude` function receives `apiKeys` as a parameter and passes it to the `client` function. If this function is called from multiple places, the API key could be logged or exposed through stack traces if errors occur.

The Gemini streaming function logs every chunk from the API response, which may contain user messages, document content, or other PII that was sent to the LLM.

The @google/genai package is imported but its version is not pinned in the visible code. This could lead to unexpected breaking changes or security vulnerabilities if a malicious version is published.

When GEMINI_API_KEY environment variable is not set and no override is provided, the function falls back to an empty string. This will cause the Google GenAI client to fail with an authentication error, but the error message may leak the empty key or cause confusing failures.

The `model` parameter in `streamGemini` is passed directly from the request without validation against an allowlist. A user could specify an arbitrary model name, potentially accessing restricted or unintended models.

The Gemini API key is passed directly from environment variables or user-provided apiKeys. There is no validation that the key is scoped to the minimum required permissions or that it hasn't been revoked.

The streaming response from the Gemini API is consumed without any integrity checks (e.g., HMAC, digital signature). A compromised or intercepted API response could inject malicious content or tool calls.

The entire Gemini stream chunk is logged to console via `JSON.stringify(chunk, null, 2)`. This may include sensitive information such as API keys, user data, or internal system details in the response.

The `completeGeminiText` function returns the model's text output directly without any validation or sanitization. A compromised model could return malicious content that is then used in downstream operations.

**Perspective 1:** The streamChatWithTools and completeText functions delegate to provider-specific implementations (streamClaude, streamGemini) but there is no explicit enforcement of TLS or certificate validation for the underlying HTTP connections to Anthropic and Google APIs. If the underlying HTTP client does not enforce TLS, API keys and prompt data could be intercepted. **Perspective 2:** The LLM client library does not enforce TLS certificate validation or specify minimum TLS version when communicating with external LLM providers. This could allow man-in-the-middle attacks on API calls to Claude, Gemini, or other providers.

The gemini module imports @google/genai without a pinned version, introducing supply chain risk from future updates.

**Perspective 1:** The code defines model IDs and provider inference but does not show any encryption or secure handling of API keys used to authenticate with LLM providers (Anthropic, Google). API keys are passed as plain strings via UserApiKeys type. If these keys are transmitted or stored without encryption, they could be exposed to interception or unauthorized access. **Perspective 2:** The codebase does not enforce TLS or any form of encryption when transmitting LLM API keys (Claude, Gemini) between the frontend and backend. API keys are sensitive credentials that should always be transmitted over encrypted channels.

The model configuration file defines canonical model IDs and their providers but does not include any provenance metadata such as model version hashes, training data hashes, or license information. This makes it impossible to verify the integrity or origin of the model artifacts being used.

**Perspective 1:** The tool schema adapters (`toClaudeTools`, `toGeminiTools`) transform OpenAI-style tool definitions for different LLM providers but perform no validation or integrity checks on the schema inputs. A compromised or malicious schema could inject unexpected tool definitions that lead to unintended model behavior. **Perspective 2:** The tools module (referenced in chatTools.ts) defines tool schemas for LLM providers, but there is no integrity verification (e.g., checksum or signature) on these schemas. If a schema is tampered with, the LLM could be instructed to call malicious tools. **Perspective 3:** The tool schema adapters accept arbitrary `OpenAIToolSchema` objects without versioning or schema evolution tracking. If the schema format changes between provider API versions, the adapters may silently produce invalid tool definitions, leading to runtime failures or unexpected model behavior.

The LLM provider types (Provider, StreamChatParams) define the interface for model interactions but include no fields for model version, commit hash, checksum, or any provenance metadata. This means the application has no mechanism to verify that the model being used is the intended one, or to detect if a model has been swapped or tampered with.

**Perspective 1:** The getSignedUrl function generates presigned URLs for R2 objects but does not validate whether the requesting user has permission to access the specific document. The function only checks if storage is enabled, not if the caller is authorized to access the key. This could allow unauthorized access to documents if the function is called without prior authorization checks. **Perspective 2:** Presigned URLs are generated without verifying that the requesting user has permission to access the specific document. This could allow users to generate URLs for documents they should not have access to, bypassing application-level access controls. **Perspective 3:** The getSignedUrl function has a default expiration of 3600 seconds (1 hour) which is hardcoded as a default parameter. While this is reasonable, there's no minimum expiration enforcement or per-request validation of the expiration time, which could lead to unnecessarily long-lived URLs if callers pass large values.

The getSignedUrl function accepts a downloadFilename parameter that is used to build the Content-Disposition header. While sanitizeDispositionFilename removes some characters, it may not handle all edge cases (e.g., unicode normalization, null bytes). An attacker could potentially inject headers or cause filename confusion.

The `buildContentDisposition` function sanitizes the filename by removing control characters and backslashes, but does not fully encode or validate the filename for all edge cases. The `sanitizeDispositionFilename` function only replaces `"` and `\` with underscores, which may not be sufficient for all malicious filenames. Additionally, the `encodeRFC5987` function does not encode all special characters that could cause issues in HTTP headers.

**Perspective 1:** The getUserIdFromRequest function extracts the Bearer token and calls admin.auth.getUser(token) to verify it. This approach makes an API call to Supabase for every request instead of locally verifying the JWT signature. While functional, it introduces a dependency on Supabase availability and doesn't validate the JWT structure, expiration, or signature locally. A more robust approach would be to verify the JWT locally using the Supabase JWT secret. **Perspective 2:** The code uses supabase.auth.getUser(token) which makes an HTTP request to Supabase's auth service for verification. This is less secure than locally decoding and verifying the JWT signature, as it introduces a dependency on an external service and does not validate the token's cryptographic integrity locally.

The getUserIdFromRequest function creates a new Supabase admin client with the service role key to verify JWT tokens. While this works, it creates an unnecessary admin client instance for every request. The service role key should be reserved for operations that need to bypass RLS, not for simple token verification.

The `getUserIdFromRequest` function uses the service role key (`SUPABASE_SECRET_KEY`) to verify JWT tokens. This is a valid approach but the service role key is loaded from environment variables and could be exposed. Additionally, the function throws Response objects with error messages that reveal server configuration details.

**Perspective 1:** The multer upload configuration accepts any file type without server-side validation of the actual file content. The accept attribute in the frontend is client-side only and can be bypassed. An attacker could upload executable files or other dangerous content. **Perspective 2:** The `singleFileUpload` function uses multer for file uploads but does not validate file content type or magic bytes. An attacker could upload a malicious file (e.g., a DOCX with embedded malware) that bypasses the extension check.

The multer upload handler accepts files with any extension and does not validate the actual file content against the declared MIME type. A malicious user could upload a file with a benign extension but malicious content.

The multer package is imported but its version is not pinned in the visible code. Multer has had past vulnerabilities (e.g., CVE-2022-24434 for denial of service). An unpinned version may introduce known CVEs.

The upload handler has a 100MB per-file limit but no per-user storage quota. An attacker could upload many files, each up to 100MB, consuming cloud storage and bandwidth. Storage costs scale linearly with upload volume.

The multer-based upload handler stores files in memory but does not enforce tenant-specific storage paths. The actual storage path is determined by the calling route handler. If any route handler uses a predictable or non-tenant-scoped storage path, files from different tenants could overwrite or be accessible to each other.

Maximum upload size is set to 100MB, which is very large and could allow disk space exhaustion attacks.

Multer is configured without file filter validation, allowing any file type to be uploaded. This could lead to malicious file uploads.

The multer configuration limits file size to 100MB and files to 1, but there is no protection against multiple concurrent uploads or chunked uploads that could bypass the size limit.

The .single() call on the Supabase query will throw if no row is found or if there's a database error. This unhandled rejection could crash the request or leak database error details to the caller.

The resolveTitleModel function falls back to DEFAULT_TITLE_MODEL when no user API keys are set. If the default model configuration is compromised or points to an untrusted model, all title generation requests would use the compromised model without any verification.

Same issue as getUserModelSettings — the .single() call can throw, leading to an unhandled rejection or error leak.

The auth middleware uses Supabase for authentication, but there is no build provenance or artifact signing for the backend code itself. Without signing, there is no way to verify the integrity or origin of the deployed backend artifacts.

The auth middleware stores the user's email in res.locals.userEmail in plaintext. This email is then accessible to all downstream middleware and route handlers. If any handler logs res.locals or includes it in error messages, the email is exposed.

The auth middleware returns distinct error messages for missing/invalid Authorization header ('Missing or invalid Authorization header'), invalid/expired tokens ('Invalid or expired token'), and server misconfiguration ('Server auth is not configured'). These different messages allow an attacker to distinguish between different failure modes, aiding in fingerprinting the authentication mechanism and potentially enumerating valid vs. invalid token formats.

The token is extracted by slicing 7 characters from the Authorization header and trimming. This could potentially accept malformed tokens if the header contains extra whitespace or unexpected characters. While the trim() call handles some cases, it doesn't validate the token format before passing it to the Supabase client.

The admin.auth.getUser(token) call is not wrapped in a try/catch. If the Supabase client throws (network error, timeout), the promise rejection will be unhandled, potentially crashing the process or leaking error details in the response.

The email is lowercased with toLowerCase() but there's no validation that the email format is correct. This could lead to issues with email-based authorization checks if malformed email addresses are stored or used in comparisons.

The POST /chat streaming endpoint has no rate limiting. A user could script thousands of chat requests to exhaust the system's LLM API quota or incur excessive costs. The credit system in UserProfileContext is client-side only and not enforced server-side.

**Perspective 1:** The POST /chat endpoint has no rate limiting, allowing an attacker to submit unlimited requests. This enables token budget exploitation — an attacker can send extremely long messages or high volumes of requests to maximize API costs. Combined with prompt injection, this could be used for denial-of-wallet attacks against the LLM provider. **Perspective 2:** The `runLLMStream` function in chatTools likely implements a tool-calling loop where the LLM can invoke tools, get results, and continue generating. There is no visible maximum iteration bound in the route handler, meaning an attacker could craft prompts that cause the LLM to enter an infinite tool-calling loop, consuming excessive tokens and API credits.

The generate-title endpoint logs errors to console.error with the error object. This could expose sensitive information about the failure.

The generate-title endpoint logs errors to console.error when title generation fails. This could expose information about the user's message content or the chat being processed.

The chat stream endpoint logs incoming request details including userId, chat_id, project_id, model, and message count to the console. While not exposing message content, this logs internal identifiers that could be useful for an attacker.

The chat streaming endpoint logs user IDs, chat IDs, project IDs, and message counts to the console. In production environments with centralized logging, this could expose user activity patterns and internal identifiers.

The chat stream endpoint logs 'resolved chatId' to the console. This exposes internal chat identifiers in production logs.

The chat streaming endpoint logs document counts, workflow counts, and API message counts to the console. This could expose information about the user's documents and workflows in production logs.

The chat stream endpoint logs LLM stream start details including apiMessageCount, docCount, and workflowCount to the console. This exposes internal state information.

The chat stream endpoint logs LLM stream finished details including fullTextLen and eventCount to the console. This exposes internal state information.

The chat streaming endpoint logs the length of the full text and event count after LLM stream completion. This could expose information about the content being generated.

The chat streaming endpoint logs error details to console.error when the LLM stream fails. This could expose sensitive information about the error context or the data being processed.

The chat stream endpoint logs stream errors to console.error with the error object. This could expose sensitive information about the failure.

The POST /chat/create endpoint does not implement rate limiting. An attacker could create thousands of chats in a short period, potentially exhausting database resources or storage.

The PATCH /chat/:chatId endpoint accepts a title from the request body but does not validate its length or content. An attacker could set an excessively long title or inject malicious content.

**Perspective 1:** pdfjs-dist is imported dynamically at runtime without a pinned version. This library has a history of CVEs (e.g., CVE-2024-4367, CVE-2023-29539) related to arbitrary JavaScript execution and XSS. The dynamic import pattern makes version tracking difficult. **Perspective 2:** mammoth is imported dynamically at runtime without a pinned version, introducing supply chain risk from future updates.

**Perspective 1:** When fetching single documents fails, the raw Supabase error message is returned to the client. This can leak database schema details, table names, or internal error information. **Perspective 2:** The database error message is directly returned to the client, potentially leaking schema or data details.

GET /single-documents/:documentId/display and GET /single-documents/:documentId/docx load the entire file into memory (downloadFile returns Buffer) before sending. For large documents, this could exhaust server memory. Additionally, there's no range request support for partial content delivery.

The GET /single-documents/:documentId/versions endpoint checks document access, but the response includes `current_version_id` which could be used to infer information about the document's state even if access is denied (the endpoint returns 404 for both 'not found' and 'access denied'). However, the timing difference between these two cases could enable timing-based enumeration.

The download-zip endpoint has no rate limiting, allowing an attacker to repeatedly download large ZIP files, potentially causing resource exhaustion or bandwidth abuse.

**Perspective 1:** The error from the Supabase query when deleting a document is not handled — if the query fails, the raw error could propagate to the client. **Perspective 2:** The database error message is directly returned to the client during document deletion.

**Perspective 1:** When fetching documents for zip download fails, the raw Supabase error message is returned to the client. **Perspective 2:** The database error message is directly returned to the client during zip download.

The accept/reject endpoints have no rate limiting, allowing an attacker to rapidly submit resolution requests, potentially causing resource exhaustion.

The version slug is generated using crypto.randomUUID() which produces a UUID v4. While UUID v4 uses random bytes, the format is constrained to a specific pattern (hex characters with dashes and fixed bits), reducing the effective entropy compared to a raw random token. For storage path identifiers that don't need to be UUIDs, a longer random string from a CSPRNG would provide better security.

The document listing endpoint has no rate limiting, allowing an attacker to enumerate documents or cause resource exhaustion.

The versionStorageKey function uses crypto.randomUUID() with hyphens stripped. While UUIDs are generally unpredictable, the storage path structure (userId/documentId/versionSlug/filename) exposes user and document IDs in the path. Combined with the signed URL endpoint, this could leak information about document organization.

**Perspective 1:** When storage write fails during version upload, the error is logged but the response only says 'Failed to upload new version.' — however, the catch block logs the error object which may contain sensitive storage path details. **Perspective 2:** Storage error details are directly returned to the client during version upload.

**Perspective 1:** When inserting a new document version fails, the raw database error is logged and a generic message is returned, but the error object may contain sensitive schema information. **Perspective 2:** The database error message is directly returned to the client during version insert.

The document upload endpoint has no rate limiting, allowing an attacker to upload a large number of documents and potentially exhaust storage or cause denial of service.

The document upload endpoint does not validate the file size or content type beyond the extension check. An attacker could upload a malicious file with a valid extension but different content type.

**Perspective 1:** When renaming a document version fails, the raw database error could be returned to the client. **Perspective 2:** The database error message is directly returned to the client during version rename.

The GET /single-documents/:documentId/display endpoint checks document access, but the response includes the document's filename and file_type even if the access check fails (the endpoint returns 404). This could be used to enumerate valid document IDs.

**Perspective 1:** When document processing fails, the error message including potentially sensitive details (file paths, processing errors) is returned to the client in the response body. **Perspective 2:** The document processing error message is directly returned to the client.

The download endpoint determines Content-Type based on file extension only. A malicious file with a misleading extension could be served with an incorrect MIME type, potentially bypassing security controls in the client.

The download endpoint streams files from R2 storage. With no rate limiting, an attacker could repeatedly download large files, consuming bandwidth and incurring egress costs. Each download also triggers a database query.

The download token is non-expiring (no timestamp or TTL in the payload). A leaked token can be used indefinitely to download the associated file.

The download route falls back to 'application/octet-stream' for unknown file types, which may cause browsers to handle files incorrectly and could be exploited for content type confusion.

The download endpoint verifies the HMAC token and checks document access, but the token encodes only the storage path and filename. If a token is leaked (e.g., in chat history), anyone with the token can download the file without additional authentication. The token does not expire.

The download endpoint has no rate limiting. An attacker could make many download requests, causing repeated database lookups and file reads from storage, potentially exhausting database connections or storage bandwidth.

The POST /projects/:projectId/chat endpoint has no rate limiting, similar to the general chat endpoint. This allows unlimited LLM requests per user, bypassing any intended credit or usage limits.

**Perspective 1:** The POST /projects/:projectId/chat endpoint has no rate limiting, allowing token budget exploitation and denial-of-wallet attacks. Same issue as the global chat endpoint. **Perspective 2:** Same issue as the global chat endpoint — the project chat streaming handler has no visible maximum iteration bound for tool-calling loops.

The project chat stream endpoint logs errors to console.error with the error object. This could expose sensitive information about the failure.

The project chat streaming endpoint logs errors to console.error when the LLM stream fails. This could expose sensitive information about the error context or the data being processed.

The document upload handler processes uploaded files and extracts structure trees. If the extraction process (mammoth for DOCX, pdfjs for PDF) follows external references or URLs embedded in the document, an attacker could craft a document that triggers SSRF during processing.

**Perspective 1:** The POST /projects endpoint allows creating new projects without rate limiting. An attacker could create thousands of projects to exhaust storage or database resources. **Perspective 2:** The POST /projects/:projectId/documents endpoint allows uploading documents without rate limiting. An attacker could upload many large files to exhaust storage or trigger excessive processing costs (DOCX-to-PDF conversion, structure extraction). **Perspective 3:** The GET /projects endpoint returns all projects accessible to the user. Without rate limiting, an attacker could enumerate projects or cause excessive database load.

**Perspective 1:** The createClient import from @supabase/supabase-js is imported but never used in this file. This indicates dead code that could be removed, but more importantly, it suggests potential confusion about which Supabase client to use (the service-role client vs. the anon client). **Perspective 2:** The createClient import is unused in this file. This is dead code that should be removed.

**Perspective 1:** When creating a project, the raw database error message is returned to the client. This can leak internal database details. **Perspective 2:** When deleting a project, the raw database error message is returned to the client. **Perspective 3:** When creating a project subfolder, the raw database error message is returned to the client. **Perspective 4:** When deleting a project subfolder, the raw database error message is returned to the client. **Perspective 5:** When fetching project chats, the raw database error message is returned to the client. **Perspective 6:** When document processing fails during upload, the exception message is included in the error response. This can leak internal implementation details. **Perspective 7:** When copying a document between projects, the raw database error message is returned to the client.

The POST /projects endpoint allows creating unlimited projects without rate limiting. An attacker could create thousands of projects to fill the database or exhaust storage quotas.

Multiple project endpoints accept project_id as a route parameter without validating it is a proper UUID. This could allow path traversal or injection attacks if the parameter is used in file system operations.

The POST /projects/:projectId/documents endpoint allows file uploads without rate limiting. An attacker could upload many files rapidly to fill storage or cause processing delays.

Multiple catch blocks in this file (e.g., lines 1040-1042, 1070-1072, 1110-1112) send the raw error message string to the client via SSE. The error message may contain internal details such as model names, API error codes, or stack traces from the LLM provider.

**Perspective 1:** When creating a tabular review, the raw database error message is returned to the client in the response body. This can leak internal database schema details, constraint names, or other sensitive information. **Perspective 2:** When updating a tabular review, the raw database error message is returned to the client. This can expose internal database details. **Perspective 3:** When deleting tabular cells during review update, the raw database error message is returned to the client. **Perspective 4:** When inserting new tabular cells, the raw database error message is returned to the client. **Perspective 5:** When deleting a tabular review, the raw database error message is returned to the client. **Perspective 6:** When clearing tabular cells, the raw database error message is returned to the client. **Perspective 7:** When regenerating a tabular cell, the raw database error message is returned to the client. **Perspective 8:** When deleting a tabular review chat, the raw database error message is returned to the client. **Perspective 9:** When an error occurs during tabular generation streaming, the exception message is sent to the client in the SSE stream. This can leak internal implementation details. **Perspective 10:** When an error occurs during tabular chat streaming, the exception message is sent to the client in the SSE stream. This can leak internal implementation details. **Perspective 11:** When LLM prompt generation fails, the error message from the catch block is returned to the client as 'Failed to generate prompt from LLM'. While generic, the 502 status code reveals the upstream dependency. **Perspective 12:** When the LLM returns an empty prompt, the message 'LLM returned an empty prompt' is returned to the client. This reveals that an LLM is being used and its behavior.

The tabular review endpoints (create, update, generate, chat) lack rate limiting. An attacker could rapidly create reviews, trigger LLM generations, or send chat messages, leading to high API costs and resource exhaustion.

The GET /tabular-review endpoint accepts project_id as a query parameter without validating it is a proper UUID or safe string. This could allow injection of malformed values that might cause database errors or unexpected behavior.

The POST /tabular-review/:reviewId/generate endpoint triggers expensive LLM API calls without rate limiting. An attacker could repeatedly call this endpoint to exhaust API quotas or incur significant costs.

The POST /tabular-review/:reviewId/chat endpoint triggers LLM API calls without rate limiting. An attacker could send many chat messages to exhaust API quotas or incur significant costs.

The catch block at line 1040 sends `String(err)` directly to the client in the SSE stream. This error object may contain internal implementation details, API keys (if they appear in error messages), or other sensitive information.

The catch block at line 1070 sends `String(err)` directly to the client in the SSE stream. This error object may contain internal implementation details.

The catch block at line 1110 sends `String(err)` directly to the client in the SSE stream. This error object may contain internal implementation details.

The DELETE /user/account endpoint allows deleting user accounts without rate limiting. While this is a destructive action, an attacker could repeatedly attempt to delete accounts (though it requires authentication). More importantly, the lack of rate limiting could allow enumeration attacks or abuse of the deletion flow.

The DELETE /user/account endpoint has no rate limiting. An attacker could repeatedly attempt account deletion, causing unnecessary load on the auth system.

**Perspective 1:** When creating a user profile, the raw database error message is returned to the client. **Perspective 2:** When deleting a user account, the raw database error message is returned to the client.

The POST /user/profile endpoint upserts user profiles without validating the request body. While it currently only uses user_id from the auth context, future changes might add body parameters without validation.

**Perspective 1:** The POST /workflows endpoint allows creating workflows without rate limiting. An attacker could create many workflows to exhaust database resources. **Perspective 2:** The POST /workflows/:workflowId/share endpoint allows sharing workflows with multiple emails without rate limiting. An attacker could spam share invitations or exhaust the workflow_shares table. **Perspective 3:** The GET /workflows endpoint returns all workflows accessible to the user. Without rate limiting, an attacker could enumerate workflows or cause excessive database load.

**Perspective 1:** The POST /workflows endpoint has no rate limiting. An attacker could create many workflows, filling the database. **Perspective 2:** The POST /workflows/:workflowId/share endpoint has no rate limiting. An attacker could share a workflow with many emails, causing database bloat.

Workflow configurations (prompts, column configs) are stored and retrieved from the database without any integrity verification. A compromised database or unauthorized modification could alter model behavior without detection.

**Perspective 1:** When creating a workflow, the raw database error message is returned to the client. **Perspective 2:** When deleting a workflow, the raw database error message is returned to the client. **Perspective 3:** When fetching or modifying hidden workflows, the raw database error message is returned to the client. **Perspective 4:** When fetching or modifying workflow shares, the raw database error message is returned to the client.

The POST /workflows endpoint allows unlimited workflow creation without rate limiting. An attacker could create thousands of workflows to fill the database.

The GET /workflows endpoint uses db.auth.admin.listUsers({ perPage: 1000 }) to fetch all users when resolving sharer information for shared workflows. This exposes the entire user directory.

Workflow endpoints accept workflow_id as a route parameter without validating it is a proper UUID. This could allow injection or unexpected behavior.

The Next.js configuration does not include any build provenance, artifact signing, or integrity verification mechanisms. There are no Content-Security-Policy headers, Subresource Integrity (SRI) hashes, or build attestations configured. This means deployed JavaScript bundles cannot be verified as originating from a trusted build process.

The Models and API Keys page allows users to configure API keys for model providers, but there is no verification that the API keys correspond to authentic model endpoints. An attacker who compromises the API key configuration could redirect model requests to a malicious endpoint.

**Perspective 1:** @radix-ui/react-dropdown-menu is imported without a pinned version, introducing supply chain risk from future updates. **Perspective 2:** @radix-ui/react-slot and class-variance-authority are imported without pinned versions, introducing supply chain risk from future updates.

**Perspective 1:** The delete account flow only uses a client-side state variable (deleteConfirm) to gate the deletion request. There is no server-side confirmation or re-authentication step. The actual API call at line 207 sends the deletion request without any additional verification beyond the existing auth token. **Perspective 2:** The account settings page does not provide any option for users to change their password. This limits users' ability to rotate credentials if they suspect compromise.

If getChat fails (network error, 404, etc.), the catch block silently redirects to /assistant. The user gets no error message explaining why they were redirected, which could be confusing and hides potential issues.

The sidebar open/close state is persisted in localStorage without encryption or integrity checks. An attacker with XSS or access to the client machine could modify this value to manipulate the UI state. While low-severity alone, combined with other vulnerabilities it could be used to hide security-relevant UI elements.

The project assistant chat page renders LLM-generated content through AssistantMessage and UserMessage components without output sanitization. The page imports and uses components that likely use rehype-raw for markdown rendering, creating an XSS vector.

The project assistant chat page with document viewer lacks session timeout controls. Extended sessions with open document viewers pose a risk of unauthorized access if the user walks away from their workstation.

Error message from fetch includes HTTP status code which can leak information about the backend to the user.

The uploadFiles function logs 'Upload failed:' to console.error with the error object. This could expose sensitive information about the failure.

The tabular review page uses the use() hook to extract params from the Promise, but there is no client-side access control check before rendering the TRView component. If an attacker can guess or enumerate review IDs, they could potentially access reviews they shouldn't have permission to view. The backend should enforce access control, but there's no client-side verification.

Tabular review deletion operations are performed without logging the event for audit purposes. SOC 2 CC6.1 requires audit trails for data deletion events.

The AddDocButton component logs upload failures to console.error. This could expose sensitive information about the upload process or file paths in browser console logs.

Upload failures are logged to console.error with the error object, which may contain sensitive information about the file upload process or internal state.

The react-markdown, remark-math, remark-gfm, rehype-katex, and katex packages are imported but their versions are not pinned in the visible code. These packages have had past vulnerabilities (e.g., rehype-katex XSS issues). Unpinned versions may introduce known CVEs.

**Perspective 1:** The `MarkdownContent` component renders LLM output using `ReactMarkdown` with custom components. While ReactMarkdown escapes HTML by default, the custom `a` tag component sets `target="_blank"` and `rel="noopener noreferrer"`, but there is no explicit sanitization of the rendered content for XSS or data leakage. **Perspective 2:** The `handleCopy` function copies the LLM response (both HTML and plain text) to the clipboard without any sanitization. An attacker who injects malicious content via prompt injection could have that content copied to the user's clipboard. **Perspective 3:** The `DocDownloadBlock` component uses `download_url` from LLM output to construct a download link. While it checks for relative URLs (`download_url.startsWith("/")`), there is no validation that the path is safe or that the file is what the LLM claims it is. **Perspective 4:** The AssistantMessage component renders LLM-generated content through ReactMarkdown with rehype-raw (as indicated by the import in the page component). This allows arbitrary HTML from the LLM to be rendered in the user's browser, creating an XSS vector if the LLM output contains malicious content.

The NEXT_PUBLIC_API_BASE_URL environment variable falls back to 'http://localhost:3001' if not set. While this is a common pattern for development, if this fallback is ever reached in production, API calls will be made over unencrypted HTTP to localhost, which could leak authentication tokens and data.

When NEXT_PUBLIC_API_BASE_URL falls back to 'http://localhost:3001', the user's Supabase access token is sent as a Bearer token over unencrypted HTTP. While this is localhost, if any local proxy or MITM tool is running, the token can be intercepted.

When a bulk edit accept/reject fails, the error message includes the HTTP status code (e.g., 'HTTP 500'). This leaks server-side error details to the client, which could aid an attacker in understanding the backend's behavior.

The fallback URL 'http://localhost:3001' for NEXT_PUBLIC_API_BASE_URL is hardcoded in multiple places. If this fallback is used in production, it could leak internal network topology or cause requests to fail in ways that reveal configuration details.

The error handler logs `e` to console and sends user-facing messages like 'Couldn't save one or more accepts.' However, the caught error object may contain sensitive stack traces or internal details that are logged.

Error objects that may contain sensitive data (request details, stack traces with internal paths) are logged via console.error. This could expose internal application details in browser console logs.

Error objects from the resolve operation are logged via console.error, potentially exposing sensitive data about the document or edit operation.

Revert error objects are logged via console.error, potentially exposing internal state details.

The full annotation object is logged via console.log when a citation is clicked. This may contain sensitive document content or metadata.

The full args object from handleEditResolved is logged via console.log. This may contain document IDs, edit IDs, and download URLs that could be sensitive.

@supabase/supabase-js is imported without a pinned version, introducing supply chain risk from future updates.

The AssistantSidePanel manages document tabs with document IDs but does not verify tenant context when loading documents. If a tab is opened with a manipulated document ID, documents from other tenants could be displayed.

The AssistantWorkflowModal component renders `selected.prompt_md` via ReactMarkdown without any sanitization. The `prompt_md` field contains the workflow prompt which is user-created content. While ReactMarkdown does not execute arbitrary HTML by default, the custom components (h1, h2, h3, p, ul, ol, li, strong, em) could be exploited if the markdown contains malicious content. There is no sanitization of the markdown content before rendering.