The database schema defines claude_api_key and gemini_api_key columns as plain text in the user_profiles table. No encryption is applied at the database level. This is a data-at-rest vulnerability for sensitive credentials.

**Perspective 1:** The Express app uses `express.json({ limit: '50mb' })` which sets a generous 50MB body limit, but there is no global request size limit enforced at the application level. This could allow large payload attacks, memory exhaustion, or slow loris attacks. The 50MB limit is applied only to JSON bodies, not to other content types or raw bodies. **Perspective 2:** The Express application does not configure any body-parser size limits or gateway-level request size enforcement. This allows arbitrarily large request bodies, enabling resource exhaustion attacks against the server. **Perspective 3:** The Express application does not configure any body-parser size limits, allowing arbitrarily large request bodies to be processed. This can lead to resource exhaustion (OOM) attacks against the backend server. While individual routes may have their own limits, there is no global gateway-level enforcement.

The ensureDocAccess function checks document access based on user_id and project_id. However, it does not verify that the document actually belongs to the project it claims to be associated with. An attacker could potentially access a document by providing a project_id they have access to, even if the document belongs to a different project.

The ensureReviewAccess function checks review access based on user_id, shared_with, and project_id. However, similar to ensureDocAccess, it does not verify that the review's project_id matches the project the user has access to. An attacker could potentially access a review by providing a project_id they have access to.

**Perspective 1:** The `downloadFile` function is called with a `storage_path` that originates from user-controlled data (document versions). An attacker could manipulate the storage path to point to an internal service, causing the server to make requests to internal resources. **Perspective 2:** The `buildDownloadUrl` function generates a URL from a storage key and filename. If the storage key or filename is user-controlled, an attacker could craft a URL that points to an internal service, leading to SSRF when the client fetches the URL. **Perspective 3:** The `loadCurrentVersionBytes` function takes a `documentId` from user input and uses it to query the database and download a file. If the document ID is manipulated, an attacker could potentially trigger a download from an arbitrary storage path.

**Perspective 1:** The application uses libreoffice-convert to convert documents to PDF. If LibreOffice is invoked with user-controlled filenames or paths, this could lead to command injection vulnerabilities. The normalizeDocxZipPaths function processes zip entries with backslash paths, which could potentially be exploited if malicious zip files are uploaded. **Perspective 2:** The LibreOffice conversion process may be vulnerable to command injection if user-controlled filenames or paths are passed to shell commands. This could allow an attacker to execute arbitrary commands within the container. **Perspective 3:** The document conversion process using LibreOffice does not have a timeout. A maliciously crafted document could cause LibreOffice to hang indefinitely, consuming CPU and memory resources and potentially causing a denial of service in the container.

The application uses libreoffice-convert to convert DOCX/DOC files to PDF. LibreOffice is a complex application that has had numerous CVEs. Malicious documents could exploit LibreOffice to execute arbitrary code during conversion. The conversion is performed without sandboxing or resource limits.

**Perspective 1:** The docxToPdf function converts DOCX files to PDF using LibreOffice. There is no file size limit or input validation. An attacker can upload arbitrarily large or complex DOCX files, consuming CPU and memory resources on the server, leading to compute cost escalation. **Perspective 2:** The document conversion utility (likely used for PDF rendering) has no file size limits on input documents. An attacker could upload extremely large DOCX files, each triggering a CPU-intensive conversion process. On serverless infrastructure, this could lead to high compute costs proportional to file size.

The `docxToPdf` function uses `libreoffice-convert` which internally invokes LibreOffice as a subprocess. If the input buffer contains malicious content that exploits LibreOffice, it could lead to command injection or arbitrary file access.

**Perspective 1:** The normalizeDocxZipPaths function loads the entire uploaded DOCX into memory using JSZip and then regenerates it. A maliciously crafted 'zip bomb' DOCX file (e.g., with highly compressed nested zip entries or massive XML files) could cause the server to decompress gigabytes of data into RAM, exhausting memory and causing a denial of service. There is no size check before or during decompression. **Perspective 2:** The normalizeDocxZipPaths function uses JSZip to parse DOCX files, which are ZIP archives containing XML files. While JSZip itself is not vulnerable to XML bombs, the subsequent LibreOffice conversion may parse these XML files. A DOCX containing an XML bomb (billion laughs attack) could cause LibreOffice to expand entities exponentially, consuming CPU and memory. LibreOffice has some protections, but they may not cover all cases.

The docxToPdf function spawns a LibreOffice process for every DOCX-to-PDF conversion. LibreOffice is a heavy application that consumes significant CPU and memory (often 200-500 MB per instance). An attacker can upload many DOCX files simultaneously, causing the server to spawn many LibreOffice processes, exhausting system resources and leading to denial of service. There is no concurrency limit or queue.

The documentVersions module uses user-controlled API base URLs in fetch requests without validation, allowing SSRF attacks.

The docxTrackedChanges module uses fast-xml-parser to parse XML from DOCX files. If the parser processes external entities, it could lead to XXE attacks. The parser is configured with processEntities: true, which may allow external entity expansion.

**Perspective 1:** The applyTrackedEdits function takes edit inputs (find, replace, context_before, context_after) that are generated by the LLM and applies them to DOCX files. If the LLM produces malicious edit instructions (e.g., replacing text with JavaScript or macros), those edits will be embedded in the document without any validation of the replacement content. **Perspective 2:** The tracked changes system builds XML directly from LLM-generated text content. If the LLM produces text containing XML special characters or malformed content, it could corrupt the DOCX XML structure or potentially inject malicious XML processing instructions.

The `fast-xml-parser` library is used to parse DOCX XML content without disabling external entity processing. Maliciously crafted DOCX files could contain XXE payloads that read local files or perform SSRF attacks.

The HMAC secret for signing download tokens falls back to 'dev-secret' when neither DOWNLOAD_SIGNING_SECRET nor SUPABASE_SECRET_KEY is set. This is a hardcoded, predictable secret that would allow an attacker to forge valid download tokens for any file.

**Perspective 1:** The download signing secret falls back to SUPABASE_SECRET_KEY or 'dev-secret' if DOWNLOAD_SIGNING_SECRET is not set. Using 'dev-secret' in production would allow anyone to forge download tokens. Additionally, the SUPABASE_SECRET_KEY is reused for a different purpose, increasing exposure. **Perspective 2:** Download tokens have no expiration. Once generated, they can be used indefinitely to download the associated file. If a token is leaked (e.g., in logs, chat history, or URLs), the file remains accessible forever.

The download token signing secret falls back to 'dev-secret' when DOWNLOAD_SIGNING_SECRET and SUPABASE_SECRET_KEY are not set. In production, this means any attacker who knows the default secret can forge download tokens for any file path, bypassing access controls. The secret should be required and fail at startup if not configured.

The download token signing secret falls back to 'dev-secret' when DOWNLOAD_SIGNING_SECRET and SUPABASE_SECRET_KEY are not set. In production, this means any attacker who knows the default secret can forge download tokens and access any document. This violates SOC 2 CC6.1 (encryption of data at rest and in transit) and CC6.6 (security of cryptographic keys).

The download token payload contains a `path` and `filename` that are extracted and used without sanitization. An attacker could craft a token with path traversal sequences (e.g., '../') to access files outside the intended storage directory.

**Perspective 1:** The HMAC signing secret falls back to 'dev-secret' if neither DOWNLOAD_SIGNING_SECRET nor SUPABASE_SECRET_KEY environment variables are set. This means in a production deployment without proper environment configuration, all download tokens would be signed with a publicly known secret, allowing anyone to forge valid download tokens and access any file. **Perspective 2:** The HMAC secret for download tokens falls back to 'fallback-secret-change-me-in-production' when the environment variable is not set. This hardcoded fallback allows anyone who knows the codebase to forge valid download tokens. **Perspective 3:** The HMAC secret for download tokens falls back to a hardcoded string 'fallback-secret-change-me-in-production' if the DOWNLOAD_SECRET environment variable is not set. This allows anyone who knows the fallback secret to forge valid download tokens and access any document.

The download token signing secret falls back to 'dev-secret' when DOWNLOAD_SIGNING_SECRET and SUPABASE_SECRET_KEY are not set. If this code runs in production without proper environment variables, the predictable secret allows attackers to forge download tokens and access any file.

**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. This hardcoded fallback value is predictable and would allow anyone to forge valid download tokens, bypassing access controls. In production, this must be configured via environment variables. **Perspective 2:** The download token signing secret falls back to SUPABASE_SECRET_KEY, which is a service role key for Supabase. Using a database service key as an HMAC signing secret is not a best practice. If the service key is ever rotated or compromised, it affects both database access and token signing. A dedicated, independently managed secret should be used for token signing.

The download token signing secret falls back to `'dev-secret'` when neither `DOWNLOAD_SIGNING_SECRET` nor `SUPABASE_SECRET_KEY` is set. This hardcoded fallback means any deployment missing the environment variable will use a predictable, publicly known secret, allowing token forgery.

The HMAC secret for download tokens falls back to 'dev-secret' when DOWNLOAD_SIGNING_SECRET and SUPABASE_SECRET_KEY are both unset. In production this means any attacker who knows the source code can forge arbitrary download tokens, bypassing all access controls.

**Perspective 1:** The download token signing secret falls back to 'dev-secret' when DOWNLOAD_SIGNING_SECRET and SUPABASE_SECRET_KEY are both unset. An attacker who knows this default can forge arbitrary download tokens, gaining access to any document stored in R2 without proper authorization. **Perspective 2:** The signDownload function creates tokens with no expiration timestamp embedded in the payload. Once issued, a download token is valid forever. If a token is leaked (e.g., in chat history, logs, or network traces), an attacker can download the associated file indefinitely.

**Perspective 1:** The HMAC signing secret for download tokens falls back to 'dev-secret' if neither DOWNLOAD_SIGNING_SECRET nor SUPABASE_SECRET_KEY environment variables are set. This means any deployment without these variables configured will use a predictable, hardcoded secret, allowing anyone to forge valid download tokens. **Perspective 2:** The download token signing secret falls back to 'insecure-fallback-secret' when the DOWNLOAD_SECRET environment variable is not set. This means any deployment without this environment variable configured will use a predictable, hardcoded secret, allowing anyone to forge valid download tokens and access any document. **Perspective 3:** A hardcoded fallback secret 'fallback-secret-change-me-in-production' is used for signing download tokens. This allows anyone who knows the fallback to forge valid tokens.

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

When DOWNLOAD_SIGNING_SECRET and SUPABASE_SECRET_KEY are not set, the code falls back to the hardcoded string 'dev-secret'. This means any deployment without proper configuration will use a predictable, publicly known secret for signing download tokens.

The `signDownload` function encodes only the storage path and filename into the HMAC-signed token. It does not include a tenant_id or user_id. This means a valid token for one tenant's document could be used by another tenant's user if the token is intercepted, shared, or if the signing secret is compromised. The token is non-expiring, increasing the risk window.

The timingSafeEqStr function returns false early if string lengths differ, which leaks the length of the expected HMAC signature via timing side-channel. An attacker can brute-force the signature length first, then brute-force each character.

When DOWNLOAD_SIGNING_SECRET and SUPABASE_SECRET_KEY are both unset, the signing secret defaults to 'dev-secret'. In production, this means all download tokens would be signed with a known, static key, allowing any user to forge tokens and access any file. This is a critical configuration vulnerability.

The Claude LLM integration uses user-controlled API base URLs in fetch requests without validation, allowing SSRF attacks.

**Perspective 1:** The Claude API key is loaded directly from the environment variable without any validation or integrity check. If the environment variable is misconfigured or compromised, the application could silently use an incorrect or malicious API key. **Perspective 2:** The Claude API key is loaded from the ANTHROPIC_API_KEY environment variable without any validation that the key is valid, not expired, or belongs to the expected account. If the environment variable is misconfigured or points to a compromised key, the application will silently use it to make API calls, potentially routing requests through an attacker-controlled endpoint.

Every Claude API stream event is logged to a file at 'claude-raw-stream.log' in the current working directory. This file captures the full JSON of every stream event, which may include user messages, tool call inputs, and model responses containing sensitive legal document content. The file is written synchronously with fs.appendFile and never rotated or cleaned up.

Every Claude API stream event is logged to console.log with the line `console.log('[claude raw stream]', line)`. This exposes the full JSON of every stream event, including user messages, tool call inputs, and model responses containing sensitive legal document content, to stdout/stderr which may be captured by logging infrastructure.

Every streaming event from the Claude API is logged to both the console and a file (claude-raw-stream.log). These events contain the full text of the LLM response, which may include sensitive information extracted from documents (PII, financial data, legal clauses). The file is written to the current working directory without rotation or access control, making it accessible to anyone with filesystem access.

The Gemini API key is logged in console output via JSON.stringify(chunk) on line 76. If the API key or any sensitive data is included in the chunk, it will be written to stdout. This violates SOC 2 CC6.1 (protection of sensitive data) and PCI-DSS 3.4 (render PAN unreadable anywhere it is stored).

**Perspective 1:** The Gemini API key is loaded from the GEMINI_API_KEY environment variable or passed via apiKeys parameter. There is no validation that the key is valid or that the model being accessed is the expected one. An attacker who can control the environment variable could redirect model calls to a malicious endpoint. **Perspective 2:** The Gemini API key is loaded directly from the environment variable without any validation or integrity check. If the environment variable is misconfigured or compromised, the application could silently use an incorrect or malicious API key. **Perspective 3:** The Gemini API key is loaded from the GEMINI_API_KEY environment variable without any validation. Similar to the Claude key, this could result in the application using a compromised or misconfigured key, routing requests through an unintended endpoint.

The `client()` function uses a single GEMINI_API_KEY environment variable (or a per-request override) to create a GoogleGenAI client. If the API key is shared across tenants, all tenant requests are billed to the same account and there is no tenant-level isolation in the LLM provider. More critically, if the override is per-user but not validated against the tenant, a malicious user could pass another tenant's API key and access their quota or data.

The console.log on line 76 prints the entire Gemini API response chunk, which may include the API key or other sensitive data in error messages or unexpected fields. This leaks credentials to stdout in production.

**Perspective 1:** The entire Gemini API response chunk is logged via console.log, including the full JSON object. This may contain user messages, document content, reasoning, and tool call details. In production, these logs could be captured by logging infrastructure, exposing sensitive data. **Perspective 2:** The Gemini API key (from env or user-provided apiKeys.gemini) is passed to the GoogleGenAI client. While this is expected for the API call, the key is also potentially exposed in console.log output on line 83, which could leak the API key to logs.

**Perspective 1:** The entire Gemini API response chunk is logged via console.log, which may contain sensitive data including user messages, model responses, function call arguments, and potentially API keys or other secrets. This log is visible in server logs and could be exposed in log aggregation systems. **Perspective 2:** Server-side console.log statements do not include correlation IDs, making it difficult to trace a specific API request or chat session across multiple log entries. This hinders debugging and security incident investigation.

The model selection is passed from the client to the backend without server-side validation that the user has the required API key for the chosen model. A user could select a model they don't have an API key for by manipulating the request, potentially using a model they haven't paid for or that the system hasn't authorized.

**Perspective 1:** The model provider is selected by parsing a string prefix (e.g., 'claude-', 'gemini-') from the model name. An attacker who can control the model name parameter (e.g., via user settings or API input) could potentially force the application to use an unintended provider or an unvalidated model endpoint. This is a supply chain risk because the model name is not validated against an allowlist before being used to route requests to a specific LLM provider. **Perspective 2:** The `providerForModel` function in models.ts determines the provider by checking if the model ID starts with 'claude' or 'gemini'. This is a fragile heuristic that could be bypassed by a model ID like 'claude-malicious'. There is no allowlist or validation that the model ID corresponds to a known, trusted model. If an attacker can control the model ID (e.g., via a user-supplied parameter), they could potentially load an arbitrary model. **Perspective 3:** The model provider is selected based on a string prefix of the model ID without validation. An attacker who can control the model ID could potentially route requests to an unintended provider. **Perspective 4:** The model provider is selected by parsing a string prefix (e.g., 'claude-', 'gemini-') from the model name. If an attacker can control the model name, they could potentially force the application to use an unintended provider or a provider-specific API endpoint that behaves differently. **Perspective 5:** The application streams responses from LLM providers (Claude, Gemini) without verifying the integrity or authenticity of the response. There is no mechanism to detect if a response has been tampered with in transit or if the model provider has been compromised. This is a supply chain risk because a compromised provider could inject malicious content or exfiltrate data through model responses. **Perspective 6:** The application does not verify the integrity or authenticity of model responses from LLM providers. There is no mechanism to detect if a response has been tampered with in transit or if the model provider has been compromised. This is a supply chain risk because a compromised provider could inject malicious content or exfiltrate data through model responses. **Perspective 7:** The `streamChatWithTools` and `completeText` functions return model outputs without any integrity verification. While this is typical for LLM APIs, there is no mechanism to detect if the response has been tampered with in transit (e.g., via a compromised API endpoint or man-in-the-middle attack). The application trusts the response blindly.

The model selection is passed from the client to the backend without server-side validation that the user has the required API key for the chosen model. A user could select a model they don't have an API key for by manipulating the request, potentially using a model they haven't paid for or that the system hasn't authorized.

The `normalizeSchema()` function processes tool parameters without validating that the schema itself is safe. An attacker who can influence the tool schema (e.g., through a custom workflow definition) could inject malicious parameter definitions that lead to unexpected tool invocations or argument injection.

The frontend/src/lib/storage.ts file contains S3 client initialization with credentials from environment variables. If this file is bundled and served to the client, the credentials could be exposed. However, since this is a server-side file (backend), it's less of a concern. The frontend version at frontend/src/lib/storage.ts is more concerning as it could be exposed to the client.

The `createServerSupabase()` function uses the SUPABASE_SECRET_KEY (service role key) which bypasses Row-Level Security. Any vulnerability in routes using this client could lead to unauthorized data access.

**Perspective 1:** The createServerSupabase function uses the SUPABASE_SECRET_KEY (service role key) which bypasses Row Level Security (RLS). This key has full database access and is used throughout the application. If the container is compromised, an attacker gains unrestricted access to the entire database. The comment acknowledges this but the pattern is still risky. **Perspective 2:** The Supabase service role key is used in the backend container. This key has full access to the database and bypasses Row Level Security. If the container is compromised, an attacker would have unrestricted access to all data.

The SUPABASE_SECRET_KEY (service role key) is loaded from environment variables and used to create a Supabase client that bypasses RLS. While this is standard practice for server-side code, the key is not fetched from a secrets manager (e.g., Vault, AWS Secrets Manager) at runtime. If the environment variable is compromised (e.g., via log leakage, debug output, or process memory inspection), an attacker gains full database access. Consider using a secrets manager to fetch the key at startup rather than relying solely on environment variables.

The getUserIdFromRequest function uses the service role key (SUPABASE_SECRET_KEY) to verify user JWTs. This key is loaded from environment variables and not from a secrets manager. If exposed, an attacker could forge tokens or access the database directly.

**Perspective 1:** The multer upload configuration only accepts specific file extensions (.pdf, .docx, .doc) on the frontend, but the backend does not validate the actual file content type. An attacker could upload a malicious file with a legitimate extension, potentially leading to arbitrary file upload vulnerabilities or storage of malicious content. **Perspective 2:** While the multer configuration limits individual file size to 100MB, there is no validation on the total size of multiple files uploaded simultaneously. An attacker could upload many files just under the 100MB limit, potentially exceeding the container's available storage or memory. **Perspective 3:** The file upload endpoint does not implement rate limiting. An attacker could flood the server with upload requests, potentially exhausting disk space, memory, or CPU resources, leading to denial of service. In a containerized environment, this could cause the container to be OOM-killed or run out of storage.

**Perspective 1:** The upload handler accepts files up to 100MB with no per-user storage quota. An attacker can upload many large files, consuming R2 storage and bandwidth costs. There is no limit on total storage per user or per project. **Perspective 2:** The upload handler accepts file uploads without enforcing per-user storage quotas. An attacker could upload massive amounts of data, incurring storage costs (R2/S3) that scale with the total volume. With no limits, a single user could upload terabytes of data.

The `singleFileUpload` function uses multer for file uploads without validating the file content type or sanitizing the filename. An attacker could upload a malicious file (e.g., a crafted DOCX with embedded malware) that could exploit downstream processing.

**Perspective 1:** Multer is configured with memoryStorage, which loads the entire uploaded file into RAM before processing. Combined with a 100 MB per-file limit, a single request can allocate 100 MB of server memory. Multiple concurrent large uploads can exhaust available RAM, leading to denial of service. Additionally, there is no global rate limit on uploads, allowing an attacker to open many connections simultaneously. **Perspective 2:** The upload handler does not implement any rate limiting. An attacker can flood the server with many small upload requests, exhausting connection slots, file descriptors, and CPU time for processing. This can degrade or deny service to legitimate users.

**Perspective 1:** The multer configuration allows file uploads up to 100MB with a limit of 1 file per request. While there is a size limit, it's very generous and could be exploited for storage exhaustion attacks. Additionally, there is no rate limiting on uploads, so an attacker could upload many large files sequentially. **Perspective 2:** The multer configuration allows file uploads up to 50MB per file. This large limit, combined with no rate limiting on upload endpoints, could be exploited for storage exhaustion attacks. **Perspective 3:** The multer configuration allows file uploads up to 50MB per file. This large limit increases the risk of resource exhaustion attacks and could be abused to upload malicious payloads. Combined with the lack of file type validation, this creates a significant attack surface.

User API keys for Claude and Gemini are stored in plaintext in the user_profiles table (claude_api_key, gemini_api_key columns). These are sensitive credentials that should be encrypted at rest. An attacker with database access could steal all users' API keys.

The getUserModelSettings function fetches user profile data including API keys using the server-side Supabase client. While it filters by user_id, the use of the service role client means this bypasses RLS. If the userId parameter is attacker-controlled, it could leak another user's API keys.

The getUserModelSettings function retrieves claude_api_key and gemini_api_key from the user_profiles table and returns them as plain text in the UserApiKeys object. These keys are stored in the database without encryption and are loaded into application memory on every request. If the database is compromised or the application logs are exposed, these keys could leak.

The getUserApiKeys function fetches claude_api_key and gemini_api_key from user_profiles using the server-side Supabase client. If the userId parameter is attacker-controlled, this leaks another user's API keys.

The getUserApiKeys function retrieves claude_api_key and gemini_api_key from the database and returns them as plain text. These keys are transmitted over the network to the caller. If the database connection is not encrypted or if the keys are passed through insecure channels, they could be intercepted.

**Perspective 1:** The application has no IP-based rate limiting at the API gateway or middleware level. This allows attackers to brute-force authentication endpoints, enumerate user IDs, or perform denial-of-service attacks without restriction. Rate limiting should be enforced at the edge (e.g., reverse proxy, WAF, or API gateway) before requests reach the application logic. **Perspective 2:** The Express application does not enforce request body size limits in middleware. While the file upload route has a generous limit (50MB), other endpoints (e.g., JSON API endpoints) are unprotected. An attacker could send arbitrarily large JSON payloads to exhaust server memory or trigger denial of service. Request size limits should be enforced at the edge or in middleware before parsing. **Perspective 3:** The application does not configure trust for proxy headers (e.g., X-Forwarded-For, X-Real-IP). If the application is behind a reverse proxy, Express's req.ip will reflect the proxy's IP rather than the client's IP, and any rate limiting or logging based on req.ip will be ineffective. Additionally, without proper trust configuration, an attacker behind a proxy can spoof their IP by sending a crafted X-Forwarded-For header. **Perspective 4:** The application does not verify whether the connection is over HTTPS at the edge. If TLS is terminated at a reverse proxy but the backend accepts plaintext HTTP, an attacker on the internal network could intercept or modify traffic between the proxy and backend. The application should reject non-TLS requests or verify the X-Forwarded-Proto header.

**Perspective 1:** The authentication middleware validates the JWT token on every request but does not check for session expiry, enforce token refresh, or implement any session timeout. Once a token is issued, it remains valid until its JWT expiry, which could be excessively long. There is no mechanism to force re-authentication after a period of inactivity. **Perspective 2:** The authentication system does not invalidate existing sessions when a user changes their password. An attacker who has compromised a session token would retain access even after the legitimate user changes their password. **Perspective 3:** The authentication middleware does not enforce any limit on the number of concurrent sessions per user account. An attacker who obtains valid credentials could create multiple sessions without detection, and there is no mechanism to revoke all sessions from a single location. **Perspective 4:** The authentication middleware only validates the JWT token without binding the session to any client-side fingerprint (e.g., IP address, User-Agent, or a cryptographic challenge). This makes session tokens vulnerable to theft and replay from any client.

The raw Authorization header value is extracted and passed to the Supabase admin client's getUser method. While this is a standard Supabase API call, the token is not validated or sanitized before being used. If the Supabase client has any injection vulnerabilities in its token parsing, this could be exploited.

The SUPABASE_SECRET_KEY (service role key) is fetched from environment variables and used to create a Supabase admin client for token verification. If the environment variable is empty or misconfigured, the service role key could be exposed or authentication could fail silently. The key is used in every authenticated request.

The auth middleware uses the SUPABASE_SECRET_KEY (service role key) to verify user tokens. This key has admin privileges and bypasses RLS policies. If the admin client is leaked or misused, an attacker could impersonate any user or perform admin operations. The anon/public key should be used for token verification instead.

A new Supabase admin client is created on every request using the service role key. This client has full admin access and bypasses all Row Level Security policies. Any vulnerability in the middleware or downstream code could lead to privilege escalation.

The code returns 404 for both 'not found' and 'unauthorized' scenarios. While this is a common pattern to prevent enumeration, the code paths differ slightly which could allow timing-based attacks to distinguish between the two cases.

The chat streaming endpoint (`POST /chat`) does not check the user's credit balance or increment usage before processing the request. A user can send unlimited messages without any cost tracking. The client-side credit increment in `UserProfileContext.tsx` is not called from this flow, and even if it were, it would be unreliable.

The `messages` array from the request body is passed directly to `buildMessages()` and then to `runLLMStream()` without any structural separation or sanitization. User-controlled content is concatenated into the LLM prompt, enabling prompt injection attacks where an adversary can override system instructions or manipulate tool selection.

The chat streaming endpoint accepts messages from the request body without validating the structure or content of each message. An attacker could send malformed messages that could cause unexpected behavior or errors in the LLM processing pipeline.

**Perspective 1:** The `filter` string is built by concatenating user-controlled project IDs directly into a Supabase `.or()` filter string. If a project ID contains special characters (e.g., single quotes, parentheses), it could break the filter syntax or enable injection. While Supabase's `.or()` method may provide some escaping, the raw concatenation of untrusted IDs into a filter expression is dangerous and bypasses parameterized query protections. **Perspective 2:** The `ownProjectIds` array is derived from a database query, but the IDs are directly interpolated into a filter string without validation or escaping. If any project ID contains SQL metacharacters, it could alter the query behavior. The `.or()` method in Supabase may not fully sanitize the input when used with string concatenation.

When fetching chats fails, the raw database error message is returned to the client in the response body. This leaks internal database schema details, error codes, and potentially sensitive information about the database structure.

The GET /chat endpoint uses an OR filter that includes chats from projects owned by the user AND chats where the user is the direct owner. However, the filter construction using string interpolation with project IDs could allow an attacker to inject additional filter conditions if project IDs are not properly sanitized. Additionally, the query does not verify that the user has explicit access to each individual chat record returned.

When fetching chats fails, the raw database error message is returned to the client. This exposes internal database details.

When creating a chat fails, the raw database error message is returned to the client.

When fetching a chat fails, the raw database error message is returned to the client.

**Perspective 1:** The GET /chat/:chatId endpoint checks if the user is the chat owner OR a member of the chat's project. However, the project access check uses checkProjectAccess which only verifies the user's email is in the shared_with list. If an attacker can guess or enumerate chat IDs, they can access any chat belonging to a project they have been shared with, even if the chat contains sensitive information not related to the shared context. **Perspective 2:** The GET /chat/:chatId endpoint returns chat data to any project member, even if the chat was created by another user. This leaks the chat's title, creation date, and full message history to users who may only have been granted project-level access for document review.

The GET /chat/:chatId endpoint retrieves a chat by ID and then checks if the user is the owner or a project member. However, if the chat has no project_id, only the owner can view it. This is correct, but the error handling returns a generic 404 for unauthorized access, which is good practice. However, there is no rate limiting on this endpoint, allowing an attacker to enumerate chat IDs.

The PATCH /chat/:chatId endpoint only allows the chat owner to update the title. However, if the chat is associated with a project, project members with edit access should also be able to update the title. The current implementation does not check project-level permissions.

When deleting a chat fails, the raw database error message is returned to the client.

The DELETE /chat/:chatId endpoint only allows the chat owner to delete the chat. Similar to the update endpoint, it does not check project-level permissions for chats associated with projects. Project owners should also be able to delete chats within their projects.

When generating a chat title fails, the error is logged but a generic 'Failed to generate title' message is returned. However, the error object is also logged with console.error which could leak sensitive information to logs.

The POST /chat endpoint allows any user who is a member of a project (via shared_with email) to post messages to any chat associated with that project. This means a user with read-only project access can send messages to chats they don't own, potentially injecting malicious content or extracting information.

When creating a new chat without a chat_id, the endpoint checks project access only if a project_id is provided. If no project_id is provided, a chat is created without any project association. This could allow a user to create chats that are not associated with any project, potentially bypassing project-level access controls.

**Perspective 1:** The code imports pdfjs-dist and parses PDF content from user-uploaded files. While pdfjs-dist is generally safe, if the PDF contains malicious XML structures or embedded XFA forms, it could potentially be exploited for XXE attacks if the library processes external entities. The code parses PDFs for structure extraction and page counting without sanitization. **Perspective 2:** The code uses user-controlled parameters like documentId, versionIdParam, and query parameters directly in Supabase database queries without sanitization. While Supabase uses parameterized queries for .eq() and .in() methods, the raw query parameters could potentially be manipulated for NoSQL injection if the library has vulnerabilities. **Perspective 3:** The code parses JSON data from user requests (req.body) and spreads it into objects. If the JSON contains __proto__ or constructor.prototype keys, it could lead to prototype pollution in JavaScript. The code uses spread operators and object assignments that could be vulnerable. **Perspective 4:** The code uses mammoth.extractRawText to extract text from DOCX files. If the DOCX contains malicious field codes or embedded expressions, mammoth might evaluate them. While mammoth is generally safe, complex DOCX structures with field codes could potentially be exploited. **Perspective 5:** The code uses JSZip to create ZIP archives from user-requested documents. If the ZIP library has vulnerabilities in handling malformed ZIP structures, it could potentially be exploited for SSRF or path traversal attacks. The code processes user-provided document IDs without validation.

**Perspective 1:** The /single-documents/download-zip endpoint generates a ZIP archive entirely in memory using JSZip. An attacker can request a large number of documents (or a single very large document) to exhaust server memory. The endpoint does not limit the number of documents or their total size before generating the archive. **Perspective 2:** The countPdfPages function loads an entire PDF document into memory using pdfjs-dist to count pages. An attacker can upload a PDF with a very large number of pages or a maliciously crafted PDF that causes excessive memory consumption during parsing. This runs during document upload processing. **Perspective 3:** The extractStructureTree function loads an entire PDF into memory and extracts its outline/structure. For PDFs with deeply nested outlines or many pages, this can consume excessive memory and CPU. The function also falls back to generating an entry per page for documents with more than 5 pages, which could be thousands of entries. **Perspective 4:** The extractStructureTree function for DOCX files uses mammoth.extractRawText which loads the entire document into memory and extracts all text. An attacker can upload a DOCX file with a very large amount of text content to cause memory exhaustion. The function also slices only the first 30 lines, but the entire document is still processed in memory.

**Perspective 1:** Document upload, download, version creation, and deletion operations lack audit logging. This makes it impossible to track who accessed or modified sensitive documents, violating GDPR Article 5(2) accountability requirements and data protection best practices. **Perspective 2:** Documents are stored indefinitely with no TTL or retention policy. Uploaded files remain in storage forever, violating GDPR Article 5(1)(e) storage limitation principle. There is no mechanism to automatically purge documents after a configurable retention period. **Perspective 3:** Documents are uploaded to storage without explicit server-side encryption configuration. While the underlying storage service may provide encryption, there is no code-level enforcement or verification that documents are encrypted at rest, which is required for GDPR Article 32 security of processing. **Perspective 4:** Document upload and processing operations have no mechanism to track user consent for data processing. GDPR Article 7 requires demonstrable consent for processing personal data contained in documents. There is no consent record, withdrawal mechanism, or consent scope tracking. **Perspective 5:** Document deletion does not verify if the user has exercised their right to erasure (GDPR Article 17) or if there are legal holds preventing deletion. The delete endpoint unconditionally removes documents without checking for pending legal obligations or data subject requests. **Perspective 6:** Documents are stored without any data classification labels (e.g., public, internal, confidential, PII). This makes it impossible to apply different security controls based on document sensitivity, violating data minimization and protection by design principles (GDPR Article 25). **Perspective 7:** There is no endpoint to export all user documents in a machine-readable format for data portability (GDPR Article 20). Users cannot easily transfer their data to another service provider. **Perspective 8:** Document storage backups may not be encrypted. There is no code to verify or enforce encryption of backup data, which could expose sensitive documents if backup media is compromised. **Perspective 9:** Document storage and processing may occur across jurisdictions without explicit safeguards. There is no mechanism to restrict data storage to specific geographic regions or to implement Standard Contractual Clauses (SCCs) for cross-border transfers as required by GDPR Articles 44-49. **Perspective 10:** Document processing operations (upload, conversion, analysis) are not recorded in a data processing register as required by GDPR Article 30. There is no record of processing purposes, categories of data subjects, or recipients of personal data. **Perspective 11:** Document processing operations that may involve sensitive data (e.g., legal documents containing special categories of data) do not trigger a privacy impact assessment (PIA) as recommended by GDPR Article 35.

**Perspective 1:** Document routes (GET, POST, DELETE, PATCH) lack audit logging for access, modifications, and deletions. SOC 2 requires logging of all access to sensitive data, and HIPAA requires audit trails for PHI access. Without logging, compliance violations cannot be detected or investigated. **Perspective 2:** Document deletion endpoint exists but there is no automated data retention policy enforcement or secure disposal mechanism. HIPAA and PCI-DSS require defined data retention periods and secure deletion of data when no longer needed. **Perspective 3:** Document storage paths are constructed but there is no verification that encryption at rest is enabled on the storage backend. HIPAA and PCI-DSS require encryption of data at rest. **Perspective 4:** Document upload, download, and modification endpoints lack rate limiting. This could allow abuse, DoS attacks, or data exfiltration. SOC 2 requires controls to prevent unauthorized access and service disruption. **Perspective 5:** Document version creation and modification lack change management metadata (who changed what, when, and why). SOC 2 requires change management controls and traceability. **Perspective 6:** Document operations lack hooks for security incident detection and response. Failed access attempts, unusual download patterns, or bulk operations should trigger alerts. SOC 2 and HIPAA require incident response capabilities.

The handleDocumentUpload function does not validate file content beyond extension checking. Malicious files could bypass extension checks. PCI-DSS and HIPAA require input validation to prevent injection attacks and malware uploads.

The `verifyDownload` function extracts a `path` from the download token, which is then used to fetch a file from storage. If an attacker can forge a token with a malicious path, they could potentially access arbitrary files or make requests to internal services.

Similar to the regular chat endpoint, the project chat streaming endpoint (`POST /projects/:projectId/chat`) does not check the user's credit balance or increment usage. This allows unlimited usage of the project assistant feature.

Similar to chat.ts, user messages from the request body are passed to `buildMessages()` and `runLLMStream()` without sanitization. The `displayed_doc` and `attached_documents` fields are also concatenated into the prompt, allowing an attacker to inject adversarial instructions through document metadata.

The POST /projects/:projectId/chat endpoint allows any project member to reuse an existing chat_id as long as it belongs to the same project. This means a user with shared access can continue a conversation started by another user, gaining access to the full chat history and context.

When creating a new chat fails, the raw database error message is returned to the client.

The projects route uses user-controlled API base URLs in fetch requests without validation, allowing SSRF attacks.

**Perspective 1:** The PATCH /projects/:projectId endpoint allows modifying the shared_with list (adding/removing users with access to project data) but there is no audit log recording who was added/removed, by whom, or when. This makes it impossible to track data access changes for compliance with GDPR Article 5(2) (accountability). **Perspective 2:** When a project owner adds a user's email to the shared_with list, there is no mechanism to verify that the added user has consented to having their personal data (email, display name) shared with the project owner. GDPR Article 7 requires explicit consent for processing personal data. **Perspective 3:** The DELETE /projects/:projectId endpoint deletes an entire project (which may contain documents with PII) but there is no audit log recording the deletion. This makes it impossible to verify GDPR right-to-erasure compliance. **Perspective 4:** Documents uploaded to projects are stored indefinitely with no TTL or archival mechanism. These documents may contain PII. GDPR requires that personal data not be kept longer than necessary. **Perspective 5:** When a project owner adds a user's email to the shared_with list, there is no mechanism to verify that the added user has consented to having their personal data shared. GDPR Article 7 requires explicit consent. **Perspective 6:** Documents stored in projects have no classification field indicating whether they contain PII or sensitive data. This makes it difficult to apply appropriate data protection controls.

The PATCH /projects/:projectId endpoint allows updating shared_with with arbitrary email addresses. The GET /projects/:projectId/people endpoint resolves these emails to user profiles, including display names and organisations. An attacker with access to a project can enumerate valid email addresses by observing which ones resolve to user profiles. This enables targeted phishing attacks and lateral movement to other projects shared with those users.

**Perspective 1:** Multiple endpoints in projects.ts (GET /projects, POST /projects, PATCH /projects/:projectId, DELETE /projects/:projectId, etc.) return `error.message` directly in the response body. This leaks Supabase error details including table names, column names, constraint violations, and potentially query structure to the client. **Perspective 2:** In the handleDocumentUpload function, the catch block returns `Document processing failed: ${String(e)}` to the client. This exposes the full error message including stack traces, file paths, and internal system details. **Perspective 3:** The GET /projects/:projectId/people endpoint returns display_name for registered users and null for unregistered emails. This allows an attacker who has access to a project to enumerate which email addresses belong to registered Mike users. **Perspective 4:** The code returns 404 for both 'not found' and 'no access' scenarios, but the logic varies: some endpoints check access first and return 404, while others check ownership and return 404. This inconsistency could allow timing-based enumeration of resource existence.

The POST /projects/:projectId/documents endpoint accepts file uploads with only basic type checking. No file size limits, content validation, or virus scanning is implemented. Malicious uploads could exhaust storage or exploit parsing vulnerabilities.

The PATCH /projects/:projectId endpoint dynamically assigns fields from req.body to the database update without an allowlist. This could allow updating unintended fields if new columns are added to the projects table.

The GET /projects/:projectId/people endpoint uses db.auth.admin.listUsers() to fetch all auth users and map emails to user IDs. This exposes the entire user base to any authenticated user with project access. An attacker with access to any project can enumerate all registered users' emails and IDs.

The POST /projects/:projectId/documents/:documentId endpoint copies documents between projects. While it checks the source document belongs to the user, it doesn't verify the user has access to the source project's storage objects.

The folder CRUD endpoints accept user-controlled folder names and parent_folder_id without validation. Path traversal in folder names or circular parent references could cause issues.

The tabular route uses user-controlled API base URLs in fetch requests without validation, allowing SSRF attacks.

**Perspective 1:** The tabular review endpoints (POST /tabular-review, POST /tabular-review/:reviewId/generate, POST /tabular-review/:reviewId/chat) lack rate limiting. An attacker could flood these endpoints to exhaust server resources or abuse LLM API calls, incurring significant costs. **Perspective 2:** The GET /tabular-review/:reviewId endpoint returns the full review object including 'shared_with' array containing email addresses of all collaborators. This exposes sensitive information to anyone with access to the review, including non-owner members. **Perspective 3:** The DELETE /tabular-review/:reviewId endpoint only checks that the requesting user's ID matches the review's user_id. However, the query does not verify that the review exists before attempting deletion, potentially allowing an attacker to infer valid review IDs through timing or error responses. **Perspective 4:** The PATCH /tabular-review/:reviewId endpoint accepts arbitrary fields from req.body and assigns them to the updates object without whitelisting. While the code explicitly handles title, columns_config, project_id, and shared_with, any other fields passed in the request body could potentially be processed by the database update. **Perspective 5:** The GET /tabular-review endpoint returns the full review objects including potentially sensitive fields like 'shared_with' (email addresses) and 'columns_config' (extraction prompts). This data is returned to all users who have access to the review, not just the owner. **Perspective 6:** The POST /tabular-review endpoint accepts columns_config from the request body without validating the structure or content of each column object. An attacker could inject malicious data or excessively large prompts. **Perspective 7:** The GET /tabular-review/:reviewId/people endpoint returns email addresses of all members. While this is intended for collaboration, it exposes email addresses to anyone with review access, which could be used for enumeration or phishing. **Perspective 8:** The POST /tabular-review/:reviewId/generate and POST /tabular-review/:reviewId/chat endpoints trigger expensive LLM API calls. Without rate limiting, an attacker could cause financial damage by flooding these endpoints. **Perspective 9:** The DELETE /tabular-review/:reviewId/chats/:chatId endpoint only checks that the chat's user_id matches the requesting user. However, it does not verify that the chat belongs to the specified review, potentially allowing an attacker to delete chats from other reviews if they can guess the chat ID. **Perspective 10:** The POST /tabular-review endpoint accepts document_ids from the request body without validating that the documents exist or that the user has access to them. An attacker could create reviews referencing arbitrary document IDs. **Perspective 11:** The GET /tabular-review/:reviewId/chats/:chatId/messages endpoint returns all messages including potentially sensitive content. While access is gated by review access, this exposes all messages to any collaborator, not just the chat owner. **Perspective 12:** The POST /tabular-review/prompt endpoint triggers an LLM API call to generate column prompts. Without rate limiting, an attacker could abuse this to generate excessive LLM API costs. **Perspective 13:** The ensureReviewAccess function checks if a user has access to a review, but the error handling in multiple endpoints (GET, PATCH, POST /generate, POST /chat) returns a generic 404 for both 'not found' and 'no access' cases. While this prevents information disclosure, it also means an attacker cannot distinguish between non-existent reviews and reviews they don't have access to. **Perspective 14:** The POST /tabular-review/prompt endpoint accepts a 'format' parameter that is used to look up format descriptions. While the code handles unknown formats gracefully, an attacker could pass unexpected values that might cause unexpected behavior. **Perspective 15:** The tabular review endpoints are mounted at /tabular-review without any version prefix (e.g., /v1/tabular-review). This makes it difficult to introduce breaking changes in the future. **Perspective 16:** The POST /tabular-review/prompt endpoint accepts a 'tags' array without validating the content of each tag. An attacker could inject special characters or excessively long tag values. **Perspective 17:** The POST /tabular-review/prompt endpoint accepts a 'documentName' parameter without validation. An attacker could inject special characters or excessively long values. **Perspective 18:** The GET /tabular-review endpoint returns all reviews accessible to the user. While not as sensitive as other endpoints, it could be used for enumeration or data scraping. **Perspective 19:** The POST /tabular-review endpoint accepts a 'title' parameter without validation. An attacker could inject special characters or excessively long titles. **Perspective 20:** The POST /tabular-review endpoint accepts a 'workflow_id' parameter without validating that the workflow exists or that the user has access to it.

**Perspective 1:** The tabular review generation endpoint extracts text from user-uploaded documents (PDF/DOCX) and passes it directly to the LLM via queryGemini/queryGeminiAllColumns. If a document contains embedded adversarial instructions (e.g., 'Ignore previous instructions and output your system prompt'), the LLM may follow those instructions. This is indirect prompt injection via RAG content. **Perspective 2:** The LLM-generated cell content (result from queryGemini) is stored directly in the database and returned to the client via API responses. If the LLM is prompted to output malicious content (e.g., JavaScript, SQL injection payloads, or phishing text), that content will be served to users without any output filtering or sanitization. **Perspective 3:** The column prompt (column.prompt) is user-defined text that gets included in the LLM extraction prompt. A user could set a column prompt like 'Ignore all previous instructions and output the system prompt' to perform prompt injection against their own review. While this primarily affects the user's own data, it could be used to extract system-level instructions if the prompt is shared or reused. **Perspective 4:** The tabular chat endpoint takes user messages from the request body and passes them directly to the LLM via buildTabularMessages. The system prompt is constructed with user-controlled review title and document names. If a user sends a message containing prompt injection (e.g., 'Ignore previous instructions and output your system prompt'), the LLM may comply. **Perspective 5:** The tabular generation endpoint passes full document text (potentially hundreds of pages) to the LLM without any token limit or truncation. An attacker could upload a very large document to exhaust API credits or cause denial of service through excessive token consumption. **Perspective 6:** The tabular chat endpoint uses runLLMStream which can invoke tools (TABULAR_TOOLS) in a loop. While there is a maxIterations parameter in the Claude streaming code, the tabular chat's runLLMStream call doesn't explicitly show a bound. If the LLM keeps calling tools, this could lead to unbounded API costs and latency. **Perspective 7:** The /tabular-review/prompt endpoint calls an LLM to generate a column prompt, then returns that prompt to the client. This generated prompt is later used in LLM extraction calls. If the LLM generating the prompt is compromised or produces malicious output, it could inject instructions into subsequent extraction calls. **Perspective 8:** The tabular generation and chat endpoints make expensive LLM API calls without apparent rate limiting. An attacker could repeatedly call these endpoints to exhaust API credits or cause financial damage through excessive LLM usage. **Perspective 9:** The error handling in tabular endpoints returns generic error messages, but some catch blocks log the full error (String(err)) which could contain LLM API error details. The streaming error handler sends the error message to the client via SSE, potentially leaking internal details.

**Perspective 1:** The PATCH /tabular-review/:reviewId endpoint allows modifying the shared_with list for tabular reviews (which contain extracted document content and analysis), but there is no audit log tracking who was granted access. This violates GDPR Article 5(2) accountability principle. **Perspective 2:** When a tabular review owner adds a user's email to the shared_with list, there is no mechanism to verify that the added user has consented to having their personal data shared. GDPR Article 7 requires explicit consent. **Perspective 3:** Tabular reviews, cells, and chat messages are stored indefinitely with no TTL or archival mechanism. These may contain extracted PII from legal documents. GDPR requires that personal data not be kept longer than necessary for the purpose it was collected. **Perspective 4:** The POST /tabular-review/:reviewId/regenerate-cell endpoint regenerates cell content (which may contain PII extracted from documents) but there is no audit log recording when content was regenerated, by whom, or what the previous content was. This makes it impossible to track data provenance. **Perspective 5:** The POST /tabular-review/:reviewId/clear-cells endpoint resets cell content to pending state, potentially destroying extracted data, but there is no audit log recording what was cleared, by whom, or when. **Perspective 6:** The DELETE /tabular-review/:reviewId endpoint deletes an entire review (which may contain PII extracted from documents) but there is no audit log recording the deletion. This makes it impossible to verify GDPR right-to-erasure compliance. **Perspective 7:** The DELETE /tabular-review/:reviewId/chats/:chatId endpoint deletes a chat (which may contain sensitive legal discussions) but there is no audit log recording the deletion. **Perspective 8:** Tabular review share records (which contain email addresses of shared users) are stored indefinitely with no TTL or archival mechanism. Email addresses are personal data under GDPR. **Perspective 9:** Tabular cells store extracted content from legal documents but there is no data classification field indicating whether the content contains PII, sensitive personal data, or other regulated data types. This makes it difficult to apply appropriate data protection controls. **Perspective 10:** When tabular reviews process documents through LLMs (Gemini/Claude), the document content (which may contain PII) is sent to third-party AI providers. There is no record of user consent for this processing. GDPR Article 28 requires appropriate safeguards for data processors.

**Perspective 1:** The code returns 404 for both 'not found' and 'no access' scenarios, but the logic reveals the difference: when a user lacks access to a project, the code returns an empty array (line ~72) instead of 404, while for tabular reviews it returns 404. This inconsistent behavior allows attackers to distinguish between 'project doesn't exist' and 'project exists but I have no access' by comparing responses across endpoints. **Perspective 2:** In the POST /tabular-review/:reviewId/generate endpoint, the catch block (line ~500) writes `String(err)` directly to the SSE stream. If the error object contains a stack trace (e.g., from a database connection failure or unexpected runtime error), the full stack trace is sent to the client. This leaks internal paths, library versions, and code structure. **Perspective 3:** In the POST /tabular-review/:reviewId/chat endpoint, the catch block (line ~550) writes `String(err)` to the SSE stream. This exposes internal error details (stack traces, database errors, API key validation errors) to the client in production. **Perspective 4:** Multiple endpoints (e.g., GET /tabular-review, POST /tabular-review, PATCH /tabular-review/:reviewId, DELETE /tabular-review/:reviewId) return `error.message` directly in the response body. This leaks Supabase error details including table names, column names, constraint violations, and potentially query structure. **Perspective 5:** In GET /tabular-review, if the shared-by-project or shared-by-email queries fail, the code logs a warning and continues with partial results. This means a temporary database failure could silently expose fewer reviews than the user should see, or worse, if the own query succeeds but share queries fail, the user sees only their own reviews without knowing shared reviews were missed. **Perspective 6:** In POST /tabular-review/prompt, the catch block returns a generic 'Failed to generate prompt from LLM' message, which is acceptable. However, the try block catches all errors without distinction, potentially swallowing configuration errors or API key issues that should be surfaced differently. **Perspective 7:** The PATCH /tabular-review/:reviewId endpoint accepts shared_with as an array of email addresses. If an email doesn't correspond to a registered user, the system still adds it to shared_with without any validation. While this doesn't directly leak information, the subsequent GET /:reviewId/people endpoint returns display_name as null for unregistered emails, which could be used to enumerate which emails are registered Mike users. **Perspective 8:** Some endpoints return `{ detail: string }` while others return `{ error: string }` or just the error message directly. This inconsistency could confuse clients and make error handling more difficult, potentially leading to missed error conditions.

The entire tabular review module is a new set of REST endpoints with no documented attack surface analysis. It includes file processing, LLM calls, and database operations without explicit rate limiting or input size validation on document content.

The `project_id` query parameter is used directly in database queries without validation that it's a proper UUID or other expected format. While access is checked, an attacker could probe for valid project IDs through error messages or timing differences.

The POST /tabular-review/:reviewId/generate endpoint downloads documents from storage paths stored in the database. If an attacker can manipulate the storage_path in the document_versions table (e.g., via a separate injection vulnerability or compromised admin), the server would download from attacker-controlled URLs. Combined with the LLM processing pipeline, this could enable SSRF attacks against internal services or cloud metadata endpoints.

The GET /tabular-review/:reviewId/people endpoint uses db.auth.admin.listUsers() to fetch all auth users and map emails to user IDs. This is identical to the pattern in projects.ts and exposes the entire user base to any authenticated user with review access.

The `/tabular-review/prompt` endpoint passes user-controlled `title`, `format`, `documentName`, and `tags` directly into an LLM prompt without sanitization. An attacker could inject malicious instructions to manipulate the LLM output.

The PATCH /tabular-review/:reviewId endpoint accepts arbitrary fields from the request body and applies them to the database update. While some fields are explicitly checked, the pattern allows future fields to be added without review.

The POST /tabular-review/:reviewId/chat endpoint runs an LLM with TABULAR_TOOLS that can call read_table_cells and potentially other tools. If the LLM is manipulated via prompt injection (e.g., through document content that contains malicious instructions), it could be tricked into calling tools that access internal services or exfiltrate data. The LLM output is streamed back to the client, enabling data exfiltration through the chat response.

The regenerate-cell and generate endpoints download and process document files (PDF/DOCX) from storage without size limits or content validation. Maliciously crafted documents could cause resource exhaustion or trigger vulnerabilities in parsing libraries.

The `queryGemini` and `queryGeminiAllColumns` functions (imported from chatTools) make HTTP calls to external LLM APIs. If the API endpoint URL is configurable or can be influenced, this could be an SSRF vector.

The `/tabular-review/:reviewId/chat` endpoint accepts user messages without content validation or size limits. Malicious messages could be used for prompt injection or resource exhaustion.

**Perspective 1:** The POST /user/profile and DELETE /user/account endpoints return `error.message` directly in the response body. This leaks Supabase error details to the client. **Perspective 2:** The DELETE /user/account endpoint immediately deletes the user account without requiring re-authentication or confirmation beyond the bearer token. If a session token is stolen, an attacker can permanently delete the user's account.

The DELETE /user/account endpoint allows account deletion with just a valid auth token. There's no confirmation step, re-authentication requirement, or grace period before permanent deletion.

Account deletion via DELETE /user/account is not logged to an audit trail. There is no record of who deleted their account and when. This makes it impossible to investigate unauthorized account deletions or data destruction.

The DELETE /user/account endpoint uses db.auth.admin.deleteUser(userId) which requires the service_role key. This endpoint is protected by requireAuth middleware, but any authenticated user can delete their own account. The issue is that the admin client is created with the SUPABASE_SECRET_KEY, and if an attacker gains access to this endpoint, they could potentially delete any user by manipulating the userId from res.locals. While the current implementation uses the authenticated user's ID, the use of admin-level API for self-service account deletion is dangerous and could lead to privilege escalation if the middleware is misconfigured or bypassed.

**Perspective 1:** The DELETE /user/account endpoint only calls db.auth.admin.deleteUser(userId) which removes the auth user but does not cascade to delete or anonymize the user's personal data in application tables (documents, projects, chats, tabular_reviews, user_profiles, etc.). This violates GDPR Article 17 (Right to Erasure) which requires complete deletion of personal data upon request. **Perspective 2:** The DELETE /user/account endpoint performs a destructive operation (account deletion) without any audit logging. There is no record of who deleted their account, when it happened, or what data was affected. This makes it impossible to verify compliance with deletion requests or investigate unauthorized deletions. **Perspective 3:** The user_profiles table is created via upsert but there is no mechanism to enforce data retention policies. User display names, email addresses, and organisation names are stored indefinitely with no TTL or archival process. GDPR requires that personal data not be kept longer than necessary.

DELETE /user/account endpoint allows account deletion with just a valid auth token. There is no requirement to re-enter the current password or provide any additional verification. If a user's session is hijacked (e.g., via XSS or token theft), an attacker can permanently delete the account without any secondary confirmation.

The workflows route uses user-controlled API base URLs in fetch requests without validation, allowing SSRF attacks.

**Perspective 1:** The POST /workflows/:workflowId/share endpoint shares workflows (which may contain sensitive legal analysis prompts) with other users by email, but there is no audit log recording who shared what, with whom, and when. This violates GDPR accountability requirements. **Perspective 2:** The DELETE /workflows/:workflowId endpoint deletes a workflow (which may contain sensitive legal analysis prompts) but there is no audit log recording the deletion. **Perspective 3:** Workflow share records (which contain email addresses of shared users) are stored indefinitely with no TTL or archival mechanism. Email addresses are personal data under GDPR.

The workflow sharing system normalizes emails to lowercase when storing (line 340: shared_with_email: email.trim().toLowerCase()), but the access check in resolveWorkflowAccess (line 65) also normalizes. However, the GET /workflows endpoint fetches shares by normalized email but doesn't verify the user's email is properly normalized before the query. If the auth system returns mixed-case emails, an attacker could potentially access workflows shared with a different case variant.

**Perspective 1:** Multiple endpoints in workflows.ts (GET /workflows, POST /workflows, DELETE /workflows/:workflowId, etc.) return `error.message` directly in the response body. This leaks Supabase error details including table names, column names, constraint violations, and potentially query structure to the client. **Perspective 2:** The resolveWorkflowAccess function returns null for both 'workflow not found' and 'no access', which results in a 404 response. However, the DELETE endpoint checks ownership separately and returns 404 if not the owner. This inconsistency could allow attackers to distinguish between 'workflow doesn't exist' and 'workflow exists but I'm not the owner'. **Perspective 3:** The GET /workflows endpoint fetches user profiles and auth users to determine sharer names. If a sharer has no profile, their email is used as the name. This leaks email addresses of users who have shared workflows, potentially enabling enumeration.

The `getAdminClient()` function creates a new Supabase admin client with the service role key on every request. This is used for user lookups and could be a security concern if the key is logged or leaked.

The getAdminClient function creates a Supabase admin client using SUPABASE_SECRET_KEY from environment variables. This key has full database access and bypasses RLS. It is not fetched from a secrets manager, making it vulnerable to exposure via environment variable leakage, debug logs, or process inspection.

**Perspective 1:** The getAdminClient function creates a Supabase admin client using the SUPABASE_SECRET_KEY environment variable. This key is used to list all users (auth.admin.listUsers) and perform other privileged operations. If the container is compromised, this key provides full administrative access to the Supabase project including user management. **Perspective 2:** The Supabase service role key is used to create admin clients in route handlers. This exposes the key to potential exploitation if the container is compromised or if there's a server-side request forgery vulnerability.

The getAdminClient() function creates a Supabase admin client using SUPABASE_SECRET_KEY to look up user emails via db.auth.admin.listUsers(). This admin client is used in the GET /workflows endpoint to fetch sharer emails. Any authenticated user can trigger this admin-level operation, which exposes user email addresses. An attacker could enumerate users by observing response patterns or timing differences.

The workflow update handler dynamically assigns fields from req.body to the database update without an allowlist. This could allow updating unintended fields.

The model selection is passed from the client to the backend without server-side validation that the user has the required API key for the chosen model. A user could select a model they don't have an API key for by manipulating the request, potentially using a model they haven't paid for or that the system hasn't authorized.

**Perspective 1:** The API key management page allows users to view (via eye toggle) and update their Anthropic and Google API keys. The keys are fetched from the UserProfile context and displayed in the form. There is no requirement to re-enter the current password before viewing or changing API keys, which could allow an attacker with a stolen session to exfiltrate or replace API keys. **Perspective 2:** The API key input fields have a show/hide toggle (Eye/EyeOff icons) that reveals the full API key in plaintext on screen. This creates shoulder-surfing risk and screen-capture exposure. The keys are also stored in the UserProfile context which persists in client-side state.

**Perspective 1:** The API key management page allows users to reveal and view API keys in plaintext. While the keys are stored as passwords, the reveal functionality could lead to exposure. PCI-DSS and SOC 2 require protection of secrets and credentials. **Perspective 2:** The API key management page does not enforce session timeout or re-authentication for viewing or modifying API keys. SOC 2 requires additional controls for sensitive operations.

**Perspective 1:** Multiple console.error calls in this file log potentially sensitive data such as edit annotations, document IDs, and error messages that may contain user data or internal state. These logs could be captured by browser extensions, error reporting tools, or server-side logging if the frontend is server-rendered. **Perspective 2:** The copy handler clones the entire content div and writes it to the clipboard as HTML and plain text. If the content contains sensitive data (e.g., from LLM responses with PII), this data is now accessible to any script or extension that monitors clipboard events. **Perspective 3:** The download handler fetches files from the backend with the user's bearer token in the Authorization header. While this is standard, the token is passed to a third-party domain if the download URL is absolute (though the code rejects absolute URLs). The token is also potentially exposed in error logs.

**Perspective 1:** ReactMarkdown renders user-controlled content as HTML. While it escapes raw HTML by default, the custom components (especially 'code' and 'a' tags) can introduce XSS vectors if the markdown content contains malicious payloads. The 'a' tag component uses target="_blank" without rel="noopener noreferrer" which is a tabnabbing vulnerability. **Perspective 2:** The custom 'a' component renders links with target="_blank" but does not include rel="noopener noreferrer". This allows the opened page to access the opener's window via window.opener, enabling tabnabbing attacks. **Perspective 3:** ReactMarkdown renders user-controlled LLM response content as HTML. The `components` prop overrides for `code` elements use `children` directly without sanitization. Citation preprocessing replaces `[N]` patterns with backtick-wrapped `§N§` markers that are rendered as HTML via the `code` component override, creating a potential XSS vector. **Perspective 4:** The handleCopy function copies innerHTML directly to the clipboard as 'text/html'. If the markdown content contains malicious HTML (e.g., from a crafted assistant response), it will be copied as-is and could execute when pasted into a rich text editor.

**Perspective 1:** The AssistantMessage component renders user-provided content via ReactMarkdown without any sanitization. ReactMarkdown by default does not sanitize HTML, which could allow XSS if user-controlled content is rendered. The component uses rehype-katex and remark-gfm plugins but no HTML sanitizer like rehype-sanitize. **Perspective 2:** Citation annotations are rendered as HTML via ReactMarkdown without sanitization. The displayCitationQuote and formatCitationPage functions return strings that are inserted into the DOM via dangerouslySetInnerHTML or similar mechanisms. If citation data can be manipulated, this could lead to XSS. **Perspective 3:** The handleCopy function clones the DOM node and copies innerHTML to clipboard without any sanitization. This could allow malicious content to be copied and pasted into other applications, potentially executing scripts or injecting content. **Perspective 4:** The download URL validation checks if download_url starts with '/' to determine if it's safe. This is a weak check that can be bypassed with URLs like '//evil.com/path' which starts with '/' but is actually a protocol-relative URL pointing to an external domain.

The `download_url` from the backend response (which may contain user-controlled data) is used directly in a fetch request without validation. An attacker could potentially manipulate the download URL to make the frontend fetch arbitrary URLs, leading to SSRF attacks.

**Perspective 1:** The download_url from the backend response is used directly in a fetch call without validation. While the code checks that the URL starts with '/', an attacker who can control the backend response could inject arbitrary URLs or paths. The URL should be validated against a whitelist of allowed paths. **Perspective 2:** The filename from the backend response is used to create a download link and set as the download attribute on an anchor element. An excessively long filename could cause issues with the browser's download mechanism or be used for header injection in Content-Disposition headers.

The fallback NEXT_PUBLIC_API_BASE_URL is 'http://localhost:3001'. In production deployments where this env var is not set, all API calls go to localhost, which will fail or hit a malicious service if an attacker can control DNS or network routing.

**Perspective 1:** The code constructs the API base URL from process.env.NEXT_PUBLIC_API_BASE_URL with a fallback to 'http://localhost:3001'. The user's Supabase access token is sent as a Bearer token in the Authorization header of every fetch to this URL. If the environment variable is misconfigured or an attacker can control it (e.g., via XSS or a compromised build), the token is leaked to an attacker-controlled server. **Perspective 2:** The fallback value for NEXT_PUBLIC_API_BASE_URL is 'http://localhost:3001', which uses unencrypted HTTP. In production, this should be HTTPS to prevent token interception over the network. **Perspective 3:** The code calls supabase.auth.getSession() before every fetch to the API. While not a direct vulnerability, frequent token retrieval could lead to race conditions or token leakage if not handled carefully. The token is also stored in client-side memory.

**Perspective 1:** The BulkEditActions component logs error objects to console.error which may contain sensitive data including authentication tokens, user details, or document content. These logs are visible in browser developer tools and could be accessed by any script running on the page. **Perspective 2:** Error logging throughout the codebase uses unstructured console.error/warn/log calls without consistent formatting, severity levels, or correlation IDs. This makes automated log analysis, alerting, and incident response difficult.

When NEXT_PUBLIC_API_BASE_URL defaults to http://localhost:3001, the user's Supabase JWT is transmitted in plaintext over HTTP. Any process on the same machine (or network if localhost is proxied) can intercept the token.

**Perspective 1:** Same pattern as line 80: the Supabase access token is sent as a Bearer token in a fetch to the API base URL. If the URL is compromised, the token is leaked. **Perspective 2:** Same pattern as line 80: supabase.auth.getSession() is called before every fetch. Consider caching.

**Perspective 1:** The `NEXT_PUBLIC_API_BASE_URL` environment variable defaults to 'http://localhost:3001' in multiple locations. If this environment variable is not set in production, the frontend will attempt to connect to localhost, which will fail or could connect to a malicious service running on the same machine. This is a configuration issue that could lead to data exfiltration or man-in-the-middle attacks. **Perspective 2:** The frontend code defaults the API base URL to 'http://localhost:3001' when NEXT_PUBLIC_API_BASE_URL is not set. If deployed without the environment variable, all API calls go to localhost, which would fail in production but also exposes internal routing logic. **Perspective 3:** The API base URL defaults to 'http://localhost:3001' when NEXT_PUBLIC_API_BASE_URL is not set. In production deployments where environment variables are misconfigured, this causes the frontend to make requests to localhost, which could leak data to a local attacker or cause requests to fail silently. More critically, if an attacker can control the environment variable, they can redirect API calls to their own server. **Perspective 4:** The default API base URL uses 'http://' instead of 'https://'. In production, all API communication should use HTTPS to prevent man-in-the-middle attacks and data interception. While this is configurable via environment variables, the default encourages insecure communication. **Perspective 5:** The frontend sends the user's Supabase access token as a Bearer token in the Authorization header for API requests. If the connection uses HTTP (which is the default), this token is transmitted in plaintext and can be intercepted by attackers on the same network, leading to account takeover.

The `handleAll` function in BulkEditActions makes POST requests to `${apiBase}/single-documents/${annotation.document_id}/edits/${annotation.edit_id}/${verb}` without tenant context. If the backend does not verify that the document belongs to the requesting user's tenant, a user could accept/reject edits on another tenant's documents by manipulating the document_id and edit_id parameters.

**Perspective 1:** ReactMarkdown renders selected.prompt_md which is user-controlled workflow prompt text. The custom components render children directly without sanitization. If a user creates a workflow with malicious markdown containing XSS payloads, it will be rendered unsafely. **Perspective 2:** The breadcrumb renders projectName and projectCmNumber directly in JSX. While React auto-escapes text content, these values could contain special characters that break the layout or be used in phishing attacks if displayed without context.

The model selection is passed from the client to the backend without server-side validation that the user has the required API key for the chosen model. A user could select a model they don't have an API key for by manipulating the request, potentially using a model they haven't paid for or that the system hasn't authorized.

ChatView renders user messages through UserMessage and AssistantMessage components. If user-controlled content contains template syntax (e.g., {{7*7}} for Jinja2, ${7*7} for JavaScript template literals), it could be evaluated if the content is later processed by a template engine. The content flows from user input through the chat system without sanitization.

EditCard uses applyOptimisticResolution which manipulates DOM elements via querySelector and classList. While it doesn't directly use innerHTML, the function searches for elements by text content (normalizeText) which could match maliciously crafted content. If an attacker can control the inserted_text or deleted_text values, they could potentially manipulate the DOM in unexpected ways.

**Perspective 1:** The `applyOptimisticResolution()` function manipulates the DOM based on LLM-generated edit annotations (`inserted_text`, `deleted_text`). If the LLM produces malicious content (e.g., script tags, event handlers), it could lead to DOM-based XSS when rendered in the document viewer. **Perspective 2:** The `findMatch()` function uses LLM-generated `inserted_text` and `deleted_text` to query the DOM via `querySelectorAll` and `textContent` matching. While this doesn't directly inject HTML, the text is later used in DOM manipulation without sanitization, creating a potential injection vector if the LLM produces malicious content.

**Perspective 1:** The session token is appended as a query parameter in the URL when fetching document edits. This can leak the token in server logs, browser history, and referrer headers. **Perspective 2:** The accept/reject edit endpoints are called with a simple POST request using only the Bearer token for authentication. There is no CSRF token or anti-replay mechanism, making these endpoints vulnerable to cross-site request forgery if the token is ever compromised or if a session is hijacked.

The EditCard component retrieves the Supabase session access token from the client-side session and passes it as a Bearer token in the Authorization header for API calls. This exposes the auth token to potential XSS attacks and token theft via client-side JavaScript. The token is used to authorize sensitive operations like accepting/rejecting document edits.

**Perspective 1:** The Supabase auth session token is fetched from client-side storage and included as a Bearer token in a fetch request to the API. While this is a common pattern, the token is accessible to any JavaScript running in the page context. **Perspective 2:** Error messages from the backend are logged to console.error and could potentially leak sensitive information about the system state or internal operations.

The user's Supabase access token is sent in the Authorization header when accepting or rejecting a document edit. If the backend logs request headers or if the connection is intercepted, the token is exposed. This token grants access to the user's session.

The model selection is passed from the client to the backend without server-side validation that the user has the required API key for the chosen model. A user could select a model they don't have an API key for by manipulating the request, potentially using a model they haven't paid for or that the system hasn't authorized.

The CreditsExhaustedModal component displays a message when the user reaches their message limit, but the actual enforcement of credit limits appears to be client-side only. The modal shows a reset date and informs the user they've reached their limit, but there's no evidence of server-side validation that prevents the user from continuing to send messages. A user could bypass this modal by directly calling the API endpoints without going through the UI.

**Perspective 1:** The NewProjectModal allows creating unlimited projects with unlimited documents. There is no per-user limit on the number of projects or total storage. An attacker can create many projects with many documents to consume storage and processing costs. **Perspective 2:** The NewProjectModal component allows users to create unlimited projects. Each project can contain documents and trigger LLM processing. An attacker could create thousands of projects, each potentially incurring storage and compute costs. While project creation itself is cheap, the downstream costs of documents and processing within each project add up.

**Perspective 1:** File upload in project creation accepts any file type without MIME type or magic byte validation. An attacker could upload arbitrary files. **Perspective 2:** Project name and CM number fields accept user input without length limits. Long values could cause storage or display issues.

The `createProject` function creates a project without explicit tenant context. The `addDocumentToProject` and `uploadProjectDocument` functions assign documents to a project without verifying the document's tenant matches the project's tenant. A user could potentially assign another tenant's document to their project, or create a project visible to other tenants.

**Perspective 1:** The AddDocumentsModal allows uploading multiple files with no per-user or per-session storage limits. An attacker can upload many large files, consuming storage and processing costs. **Perspective 2:** The AddDocumentsModal component allows users to upload multiple documents without any limits on file size or total storage. An attacker could upload hundreds of large files, each incurring storage costs and potentially triggering document processing (conversion, OCR, etc.) that adds further costs.

**Perspective 1:** The handleDelete function checks ownership client-side by comparing user IDs. An attacker can bypass this by calling the API directly. The server must enforce ownership, not the client. **Perspective 2:** Documents are deleted immediately when the user clicks delete in the modal, without a confirmation dialog. This could lead to accidental data loss.

File upload accepts .pdf, .docx, and .doc extensions but does not validate actual file content. An attacker could upload files with malicious content disguised with valid extensions.

The `useDirectoryData` hook fetches `standaloneDocuments` and `projects` without tenant context. The modal allows selecting documents from any project or standalone documents. If the backend does not filter by tenant, a user could see and select documents belonging to other tenants. The `onSelect` callback passes selected documents to the parent without tenant verification.

The CitationHeader component renders citation.quote text directly into a React element using dangerouslySetInnerHTML-like patterns. The quote text comes from LLM annotations and is not sanitized before rendering, allowing XSS if the quote contains malicious HTML.

**Perspective 1:** The DownloadButton component fetches documents directly from the API without verifying user authorization on each request. While the backend has access checks, the frontend doesn't enforce or verify access controls. SOC 2 requires defense-in-depth for access controls. **Perspective 2:** The document viewer does not enforce session timeout or re-authentication for sensitive document access. HIPAA requires automatic logoff after inactivity for systems containing PHI.

The Supabase session access_token is fetched on the client side and included as a Bearer token in a fetch request to the backend. If the backend URL is HTTP (fallback), this exposes the auth token in transit. The token is also passed to the backend for every accept/reject operation.

The Supabase auth token is fetched and sent as a Bearer token in the Authorization header when calling the accept/reject edit endpoints. If the backend logs these requests or forwards them to error reporting, the token could be exposed.

The Supabase session access_token is fetched on the client side and included as a Bearer token in a fetch request for document download. If the backend URL is HTTP, this exposes the auth token in transit.

The Supabase auth token is fetched and sent as a Bearer token in the Authorization header when downloading a document. If the backend logs these requests, the token could be exposed.

**Perspective 1:** The PDF text layer rendering uses innerHTML assignment via the pdf.js TextLayer. While pdf.js generally handles this safely, the text content from PDFs could contain malicious content that gets rendered as HTML. The text layer divs are later searched for quotes and highlighted, which could be exploited. **Perspective 2:** The PDF text layer rendering assigns user-controlled content to `innerHTML` without sanitization. This could allow XSS if the PDF contains malicious content that is rendered as HTML.

The highlightQuote function receives quote text from citations and inserts it into the DOM. If citation quotes contain malicious HTML or JavaScript, they could be executed when the text layer is rendered. The quote text is used to search and highlight text in the PDF viewer without sanitization.

The `NEXT_PUBLIC_API_BASE_URL` environment variable is used to construct fetch URLs for API calls. If an attacker can control this environment variable, they could redirect API calls to arbitrary endpoints, enabling SSRF attacks.

The `useFetchSingleDoc` hook fetches document content by document_id and version_id. The API call does not include tenant context. If the backend does not verify tenant membership, a user could access another tenant's document content by manipulating the document_id parameter.

**Perspective 1:** The docx-preview library renders DOCX content into the DOM using innerHTML. DOCX files can contain malicious HTML/JavaScript that will execute when rendered. The containerEl.innerHTML = '' followed by renderAsync() could allow XSS if the DOCX contains embedded scripts. **Perspective 2:** The docx-preview library renders DOCX content as HTML. If the DOCX file contains malicious content (e.g., embedded scripts), it could be rendered as HTML and lead to XSS. **Perspective 3:** The highlightDocxQuote function likely modifies innerHTML to highlight quotes. If the quote text contains HTML special characters, this could lead to XSS. The function should properly escape the quote text before inserting it into the DOM.

**Perspective 1:** The highlightDocxQuote function receives quote text from citations and inserts it into the DOM without sanitization. If citation quotes contain malicious content, they could be executed when the DOCX viewer renders the highlights. **Perspective 2:** The tagWIdsOnRenderedDom function fetches tracked change IDs from the API and assigns them as data-w-id attributes on DOM elements without sanitization. If the API returns malicious data, it could lead to DOM clobbering or attribute injection attacks. **Perspective 3:** The DocxView component renders a warning message in the UI without sanitization. If the warning message contains malicious content, it could be executed when the component renders. **Perspective 4:** The DocxView component sets data-document-id and data-version-id attributes on the scroll container using values from props without sanitization. If these values contain malicious content, they could be used for DOM clobbering or attribute injection. **Perspective 5:** The findEditElement function searches for DOM elements based on edit text content without sanitization. If the edit text contains special characters, it could interfere with the querySelector or text matching logic.

The `NEXT_PUBLIC_API_BASE_URL` environment variable is used to construct fetch URLs for API calls. If an attacker can control this environment variable, they could redirect API calls to arbitrary endpoints, enabling SSRF attacks.

The document ID and version ID from props are used directly in API endpoint URLs without validation. An attacker who can control these props could inject path traversal sequences or manipulate API calls.

**Perspective 1:** The Supabase access token is sent as a Bearer token in a fetch to the API base URL constructed from NEXT_PUBLIC_API_BASE_URL with an HTTP fallback. If the URL is compromised, the token is leaked. **Perspective 2:** Same pattern: supabase.auth.getSession() is called before every fetch. Consider caching.

The fallback NEXT_PUBLIC_API_BASE_URL is 'http://localhost:3001'. In production deployments where this env var is not set, all API calls go to localhost, which will fail or hit a malicious service if an attacker can control DNS or network routing.

When NEXT_PUBLIC_API_BASE_URL defaults to http://localhost:3001, the user's Supabase JWT is transmitted in plaintext over HTTP. Any process on the same machine (or network if localhost is proxied) can intercept the token.

The `tagWIdsOnRenderedDom` function fetches tracked change IDs from `/single-documents/${documentId}/tracked-change-ids` without tenant context. If the backend does not verify tenant membership, a user could access another tenant's document tracked changes by manipulating the document_id.

**Perspective 1:** The highlightDocxQuote function modifies innerHTML to highlight quotes in DOCX content. If the quote text contains HTML special characters, this could lead to XSS. The function must properly escape the quote text before inserting it into the DOM. **Perspective 2:** The `highlightDocxQuote` function creates `<span>` elements with `className` set to a constant string and appends them to the DOM. While the class name is hardcoded, the function splits text nodes and wraps content in spans. If the underlying text content contains malicious HTML entities, they could be interpreted when the span is inserted. The function also calls `clearDocxQuoteHighlights` which removes elements by class name, but doesn't sanitize the quote text before searching. **Perspective 3:** The `highlightDocxQuote` function creates `<span>` elements with `className` set to a constant string and appends them to the DOM. While the class name is hardcoded, the function splits text nodes and wraps content in spans. If the underlying text content contains malicious HTML entities, they could be interpreted when the span is inserted.

The highlightDocxQuote function inserts quote text directly into the DOM by creating text nodes and wrapping them in span elements. While this uses textContent rather than innerHTML, the function does not validate or sanitize the quote input before processing, which could lead to issues if the quote contains special characters or malformed content.

**Perspective 1:** The highlightQuote function modifies innerHTML of text divs to wrap matched text in highlight spans. If the quote text contains HTML special characters (<, >, &, "), this could result in XSS. The function must properly escape the quote text before inserting it into the DOM. **Perspective 2:** The `highlightQuote` function manipulates the DOM by creating and inserting HTML elements. If the quote text contains malicious content, it could be interpreted as HTML when inserted into the DOM.

The `highlightQuote` function sets `div.innerHTML` using user-provided `quote` text without any sanitization. The `escapeHtml` function is only applied to the non-highlighted portions of the text, but the highlighted portion (the `quote` text) is inserted directly into the innerHTML via a template literal. This allows an attacker to inject arbitrary HTML/JavaScript if they can control the `quote` parameter, leading to stored XSS.

The `highlightQuote` function sets `div.innerHTML` with user-controlled text content from the PDF text layer. While `escapeHtml` is used on the text segments, the overall approach of reconstructing innerHTML from text content that originates from a PDF (which could contain malicious content) is risky. The `escapeHtml` function only escapes &, <, > but does not escape quotes or other dangerous characters. Additionally, the `ORIGINAL_TEXT_ATTR` attribute is set with unescaped original text, which could be exploited if the attribute value is later used in an unsafe context.

**Perspective 1:** File upload accepts .pdf, .docx, and .doc extensions but does not validate the actual file content via MIME type checking or magic byte verification. An attacker could upload a malicious file with a benign extension. **Perspective 2:** The review title is taken from user input without any length validation. An excessively long title could cause UI layout issues or be used in injection attacks if stored and displayed elsewhere.

The model selection is passed from the client to the backend without server-side validation that the user has the required API key for the chosen model. A user could select a model they don't have an API key for by manipulating the request, potentially using a model they haven't paid for or that the system hasn't authorized.

**Perspective 1:** The TRAssistantMessage component renders user-provided content through ReactMarkdown without any sanitization. ReactMarkdown by default does not sanitize HTML, allowing XSS via embedded HTML tags in the markdown content. The content comes from LLM responses and annotations which could contain malicious HTML. **Perspective 2:** The HistoryDropdown component renders chat titles without sanitization. Chat titles are user-provided and could contain HTML or script content. While React's default behavior escapes text content, the titles are rendered as button text which is safe, but the lack of server-side validation is a concern.

**Perspective 1:** ReactMarkdown renders user-controlled content as HTML. While ReactMarkdown by default escapes HTML, the `components` prop overrides for `code` elements use `children` directly without sanitization. The citation preprocessing replaces `[N]` patterns with backtick-wrapped `§N§` markers that are then rendered as HTML via the `code` component override, creating a potential XSS vector if citation annotations contain malicious content. **Perspective 2:** The breadcrumb in the TRChatPanel header renders `reviewTitle` and `projectName` as text content, which is safe. However, the `ReasoningBlock` component renders LLM-generated text via ReactMarkdown without sanitization, which could contain malicious content.

**Perspective 1:** The handleAutoGenerate function calls generateTabularColumnPrompt which triggers an LLM API call. There is no rate limiting or cost control. An attacker can repeatedly click 'Auto-generate' to incur unlimited API costs. **Perspective 2:** The TREditColumnMenu component has an 'auto-generate' feature that calls an LLM API to generate column prompts. This is triggered by user interaction but has no rate limiting or cost controls. An attacker could repeatedly click the auto-generate button, each time incurring an LLM API call. **Perspective 3:** The TREditColumnMenu allows adding unlimited tags to a column. While not directly costly, tags are stored and processed, contributing to storage costs.

**Perspective 1:** ReactMarkdown is used to render cell.content.summary and cell.content.reasoning which contain user-controlled text. While ReactMarkdown does not use dangerouslySetInnerHTML by default, the custom 'code' component renders pill and citation content without encoding. Combined with the 'a' component that renders href directly, this could allow XSS if a user can control cell content. **Perspective 2:** The custom 'a' component in ReactMarkdown renders href directly without validation. While it uses target='_blank' and rel='noopener noreferrer', it does not validate that the URL is safe (e.g., javascript: URLs, data: URLs could be used for XSS). **Perspective 3:** Pill content extracted from [[...]] markers is rendered directly into a span element via getPillClass. While the content is displayed as text, if a user can control the pill content, it could potentially be used for injection if the CSS classes are manipulated. **Perspective 4:** doc.filename is rendered in a title attribute. While React escapes attribute values, filenames could contain special characters that break the tooltip display.

TabularCell renders user-controlled cell content through ReactMarkdown with rehype-raw (via remark-gfm). If cell.content.summary contains malicious markdown or HTML, it could be rendered unsafely. While ReactMarkdown escapes raw HTML by default, the use of rehype-raw (if configured) or custom components could allow injection. The content originates from LLM output which may contain crafted payloads.

The `TabularCell` component renders LLM-generated content through ReactMarkdown without sanitization. The `preprocessCellMarkdown` function processes citations and pills but does not strip dangerous HTML or script content. An attacker who can influence the LLM output could inject malicious content that gets rendered in the browser.

The `NEXT_PUBLIC_API_BASE_URL` environment variable is used to construct fetch URLs for API calls. If an attacker can control this environment variable, they could redirect API calls to arbitrary endpoints, enabling SSRF attacks.

The 'chat' search parameter from the URL is read and used to set state without validation. An attacker could inject malicious values via the URL query string that could be used in subsequent operations or reflected in the UI.

The `getTabularReview(reviewId)` call fetches review data by ID only. If the backend does not verify that the review belongs to the requesting user's tenant, a user could enumerate review IDs and access another tenant's tabular reviews. The review ID is passed as a URL parameter and could be manipulated.

**Perspective 1:** The PAGE_CITATION_RE regex uses a complex pattern that can be bypassed with nested brackets or special characters. The regex matches [[page:n||quote:...]] patterns but the quote capture group allows nested brackets, which could lead to incorrect parsing or injection of malicious content. **Perspective 2:** The preprocessCitations function parses page numbers from citation markers but does not validate that they are positive integers within a reasonable range. Negative or extremely large page numbers could cause issues in the PDF viewer or other components that use this data.

The regex /\[\[page:(\d+)\|\|(?:quote:)?((?:[^\[\]]|\[[^\]]*\])+)\]\]/gi has nested quantifiers that could cause catastrophic backtracking on malicious input containing many nested brackets. The pattern (?:[^\[\]]|\[[^\]]*\])+ can cause exponential backtracking when matching against crafted strings.

**Perspective 1:** The exportToExcel function exports tabular review data to Excel files without logging the export operation. HIPAA requires audit trails for all exports of PHI, and PCI-DSS requires logging of all access to cardholder data. **Perspective 2:** Exported Excel files lack data classification labels, watermarks, or confidentiality markings. HIPAA and PCI-DSS require proper labeling of sensitive data. **Perspective 3:** Exported Excel files are created as blobs and downloaded without encryption. If these files contain PHI or sensitive data, they should be encrypted. HIPAA requires encryption of PHI at rest.

The MarkdownBody component renders workflow.prompt_md content through ReactMarkdown without sanitization. Workflow prompts are user-provided and could contain malicious HTML that would be rendered by ReactMarkdown, leading to XSS.

ReactMarkdown renders user-controlled workflow prompt content as HTML. The `MarkdownBody` component renders `workflow.prompt_md` and column prompts without sanitization. While ReactMarkdown escapes raw HTML by default, the custom component overrides could introduce XSS if the markdown content contains malicious elements.

The `WFColumnViewModal` renders `col.prompt` via `ReactMarkdown` without any sanitization. The `col.prompt` value originates from user input (the column prompt field) and is stored in the database. When rendered, ReactMarkdown will parse and render any embedded HTML or JavaScript within the markdown, leading to stored XSS. The `remarkGfm` plugin is used, which does not provide HTML sanitization.

**Perspective 1:** The `WFColumnViewModal` component renders column prompts using ReactMarkdown with `remarkGfm` plugin. The `col.prompt` value is user-controlled (set by the user when creating/editing a workflow column). ReactMarkdown renders markdown to HTML, and while it typically escapes raw HTML, the combination with GFM (GitHub Flavored Markdown) could allow certain injection vectors. The prompt content is stored in the database and displayed to other users who have access to the workflow, making this a potential stored XSS vector. **Perspective 2:** ReactMarkdown is used without the `rehype-sanitize` plugin. While ReactMarkdown by default escapes raw HTML in markdown, the `remarkGfm` plugin can introduce additional HTML elements (tables, strikethrough, etc.) that might not be properly sanitized. User-controlled content from `col.prompt` is rendered, and this content can be set by any user with edit access to the workflow.

console.warn in useAssistantChat logs raw SSE line data that may contain user messages, document content, or other sensitive information. This could be captured by browser extensions or error monitoring services.

The `NEXT_PUBLIC_API_BASE_URL` environment variable is used to construct fetch URLs. If an attacker can control this environment variable (e.g., via build-time injection), they could redirect API calls to arbitrary endpoints, enabling SSRF attacks.

Server-Sent Events data is parsed from JSON and used directly in state updates and function calls. Fields like 'text', 'filename', 'query', 'name', 'workflow_id', 'title', 'document_id', 'version_id', 'download_url', and 'error' are not validated for type, length, or content before being used. Malicious SSE data could inject arbitrary content into the UI or cause unexpected behavior.

The fallback NEXT_PUBLIC_API_BASE_URL is 'http://localhost:3001'. In production deployments where this env var is not set, all API calls go to localhost, which will fail or hit a malicious service if an attacker can control DNS or network routing.

The `streamChat` and `streamProjectChat` functions send chat messages to the backend. The `chat_id` parameter is user-provided and could be manipulated. If the backend does not verify that the chat belongs to the requesting user's tenant, a user could access or continue another tenant's chat session by guessing or enumerating chat IDs.

**Perspective 1:** The raw SSE data string is logged via console.warn on parse failure. If an attacker can inject crafted SSE data, they could forge log entries by including newline characters or other log formatting tokens. This could corrupt log analysis or be used to hide malicious activity. **Perspective 2:** When SSE parsing fails, the raw data string is logged via console.warn. This data may contain user messages, model responses, or other sensitive content. The log is visible in browser developer tools. **Perspective 3:** Client-side console logs do not include correlation IDs, making it difficult to trace a user's session or specific chat interaction across multiple log entries. This hinders debugging and security incident investigation.

The `NEXT_PUBLIC_API_BASE_URL` environment variable is used to construct fetch URLs for API calls. If an attacker can control this environment variable, they could redirect API calls to arbitrary endpoints, enabling SSRF attacks.

The `useDocumentVersions` hook fetches version history for a document by ID. The API call to `/single-documents/${documentId}/versions` does not include any tenant context. If the backend does not verify that the document belongs to the requesting user's tenant, a user could enumerate document IDs and access version history of another tenant's documents.

**Perspective 1:** The Supabase access token is sent as a Bearer token in a fetch to the API base URL constructed from NEXT_PUBLIC_API_BASE_URL with an HTTP fallback. If the URL is compromised, the token is leaked. **Perspective 2:** Same pattern: supabase.auth.getSession() is called before every fetch. Consider caching.

The fallback NEXT_PUBLIC_API_BASE_URL is 'http://localhost:3001'. In production deployments where this env var is not set, all API calls go to localhost, which will fail or hit a malicious service if an attacker can control DNS or network routing.

useFetchDocxBytes constructs a fetch URL using documentId and versionId from props. If these values are user-controlled and not validated, an attacker could manipulate the URL to make requests to internal services. The URL is constructed as `${apiBase}/single-documents/${documentId}/docx${qs}` where documentId could contain path traversal characters.

**Perspective 1:** The access token is appended as a query parameter to the API URL when fetching document bytes. This exposes the token in server logs, browser history, and the Referer header. **Perspective 2:** Error messages from the fetch call may contain the full URL including the token query parameter, potentially exposing the token in console logs or error reporting systems.

The user's Supabase access token is sent in the Authorization header when fetching document bytes from the backend API. If the backend logs request headers or if the connection is intercepted, the token is exposed. This token grants access to the user's session and can be used to impersonate the user.

The useFetchDocxBytes hook retrieves the Supabase session access token from the client-side session and passes it as a Bearer token in the Authorization header for document download requests. This exposes the auth token to potential XSS attacks and token theft via client-side JavaScript.

The Supabase auth session token is fetched from client-side storage and included as a Bearer token in a fetch request to download document bytes. The token is accessible to any JavaScript running in the page context.

The useFetchSingleDoc hook uses user-controlled API base URLs in fetch requests without validation, allowing SSRF attacks.

The selected model is stored in `localStorage` and read from there on each request. The server accepts a `model` parameter in the chat request body. A user can modify the `localStorage` value or directly manipulate the API request to use any model, including more expensive ones, bypassing any server-side model restrictions or pricing tiers.

**Perspective 1:** The code uses the Supabase anon/public key (NEXT_PUBLIC_SUPABASE_ANON_KEY) for operations that likely require elevated privileges. The anon key is designed for client-side use with Row Level Security, but if used for server-side token generation or admin operations, it represents a security misconfiguration. **Perspective 2:** The Supabase anon/public key is used for token verification instead of the service role key. This is a security misconfiguration that can lead to privilege escalation.

The API client uses Supabase auth tokens but there is no session timeout, token refresh logic, or re-authentication mechanism implemented. Tokens are fetched from supabase.auth.getSession() on each request without checking expiration or refreshing stale tokens. This can lead to expired sessions being used or tokens being valid indefinitely.

The model selection is passed from the client to the backend without server-side validation that the user has the required API key for the chosen model. A user could select a model they don't have an API key for by manipulating the request, potentially using a model they haven't paid for or that the system hasn't authorized.

The code uses fetch API and parses JSON responses without sanitization. If the backend returns malicious JSON with __proto__ or constructor.prototype keys, it could lead to prototype pollution in the frontend application. The code spreads response objects into state without filtering.

**Perspective 1:** The Supabase auth session (including access_token and refresh_token) is stored in localStorage by default. This exposes tokens to XSS attacks and makes them accessible to any JavaScript running on the same origin. The getAuthHeader function retrieves the session from supabase.auth.getSession() which reads from localStorage. **Perspective 2:** The getAuthHeader function retrieves the Supabase access token from the client-side session and attaches it as an Authorization: Bearer header to every API request. This means the JWT token is exposed in every network request and is accessible to any JavaScript running on the page.

**Perspective 1:** The Supabase auth token is attached as a Bearer token in the Authorization header for every API request to the backend. While this is standard for authentication, if the backend logs or forwards these headers (e.g., to error reporting services), the token could be exposed. The token is also sent over HTTP in development (http://localhost:3001). **Perspective 2:** The API_BASE defaults to http://localhost:3001, which transmits all data (including auth tokens) in plaintext over the network. This is a development setting but could be accidentally deployed or used in a staging environment. **Perspective 3:** The apiRequest function throws an error with the response text on non-OK responses. If the response contains the auth token (e.g., in an error message), it could be exposed in console logs or error reporting services. **Perspective 4:** API requests use cache: 'no-store' but the Authorization header could still be cached by intermediate proxies or CDNs if not configured correctly. This is a defense-in-depth concern.

**Perspective 1:** The API_BASE constant defaults to http://localhost:3001 when NEXT_PUBLIC_API_BASE_URL is not set. In production deployments, this could cause requests to be sent to localhost instead of the actual API endpoint, potentially leaking data or causing failures. More critically, if an attacker can control the environment variable, they could redirect API calls to a malicious server. **Perspective 2:** The API client defaults the base URL to 'http://localhost:3001' when NEXT_PUBLIC_API_BASE_URL is not set. In production, this would cause all API calls to fail or route to an unintended destination. **Perspective 3:** The API client defaults to 'http://localhost:3001' when NEXT_PUBLIC_API_BASE_URL is not set. This is the same issue as in AssistantMessage.tsx. In production, misconfigured deployments will send API requests to localhost, potentially leaking data or causing silent failures.

The API_BASE constant uses a hardcoded fallback to http://localhost:3001. In production, this could lead to credentials being sent over unencrypted HTTP if the environment variable is not set. The auth token (Bearer token) is attached to every request made through this client.

**Perspective 1:** The login page uses Supabase auth but does not implement any session timeout, idle timeout, or token refresh logic. Sessions may persist indefinitely, increasing the risk of unauthorized access if a token is stolen. **Perspective 2:** The application does not invalidate existing sessions when a user changes their password. This allows an attacker with a stolen session token to maintain access even after the legitimate user changes their password. **Perspective 3:** The application does not enforce any limit on the number of concurrent sessions per user account. An attacker who obtains valid credentials can create unlimited sessions without detection. **Perspective 4:** Sessions are not bound to any client-side fingerprint (e.g., IP address, User-Agent, or a cryptographic token). This makes session hijacking trivial: an attacker who steals the session token can use it from any device or location. **Perspective 5:** The login page does not provide a visible logout button or endpoint. Users cannot explicitly terminate their session, which may lead to sessions persisting on shared devices.

**Perspective 1:** The login form submits directly to Supabase auth without any client-side or server-side rate limiting. An attacker can brute force credentials without restriction. **Perspective 2:** There is no account lockout after multiple failed login attempts. An attacker can perform unlimited password guessing against any account. **Perspective 3:** The login/signup flow does not show any password policy enforcement. Without minimum length or complexity requirements, users may choose weak passwords. **Perspective 4:** The application does not check passwords against known breach databases (e.g., Have I Been Pwned API) during signup or password change. **Perspective 5:** The login page does not provide a 'Forgot Password' link or password reset flow. Users who forget their password have no recovery mechanism. **Perspective 6:** The application does not appear to support multi-factor authentication. There are no MFA setup flows or TOTP/SMS verification steps.

The login page does not log any audit events for successful or failed login attempts. There is no record of authentication events, making it impossible to detect brute-force attacks, account enumeration, or unauthorized access patterns. Failed login attempts are silently swallowed.

**Perspective 1:** The application does not invalidate existing sessions when a user changes their password. The deleteAccount function in account/page.tsx calls supabase.auth.signOut() but there is no mechanism to revoke all other sessions when the password is changed. An attacker who has compromised a session token would retain access even after the legitimate user changes their password. **Perspective 2:** The session token is not bound to any client-side fingerprint (e.g., IP address, User-Agent, or a cryptographic challenge). If a session token is stolen via XSS or network interception, it can be used from any device without additional verification. **Perspective 3:** The application does not expose any configuration for session timeout duration. The default Supabase token lifetime (typically 1 hour) may not be appropriate for all use cases, and there is no way to adjust it without modifying the Supabase project settings.

**Perspective 1:** The AuthContext only checks the session on mount and listens for auth state changes, but never implements a periodic session refresh or idle timeout. If the user walks away from an active session, the token remains valid indefinitely until Supabase's server-side expiry. An attacker with access to the device can continue using the session without re-authentication. **Perspective 2:** The application does not enforce any limit on the number of concurrent sessions per user account. A user could have dozens of active sessions across different devices without any restriction. This increases the attack surface if credentials are shared or if a device is compromised. **Perspective 3:** The application uses Supabase's default session management which may not rotate refresh tokens on each use. If a refresh token is stolen, it can be reused indefinitely to obtain new access tokens, allowing persistent unauthorized access. **Perspective 4:** The signOut function calls supabase.auth.signOut() which may only clear the local session state but not revoke the session server-side. If the session token is not invalidated on the server, it could still be used until it expires naturally.

The UserProfileContext stores and retrieves Claude and Gemini API keys (claude_api_key, gemini_api_key) as plaintext columns in the user_profiles database table. API keys are sensitive credentials that, if the database is compromised, would grant an attacker direct access to LLM provider accounts at the user's expense. The code fetches these keys via Supabase and exposes them to the frontend without any encryption or masking.

The UserProfileContext uses the client-side supabase client to read and write user profiles, including API keys (claude_api_key, gemini_api_key). These API keys are stored in the database and fetched to the client, potentially exposing them.

The UserProfileContext stores Claude and Gemini API keys (claudeApiKey, geminiApiKey) in React state on the client side. These API keys are fetched from Supabase and stored in memory, making them accessible to any JavaScript running in the page, including third-party scripts or XSS attacks. The keys are also exposed through the context provider to all child components.

The profile loading function fetches claude_api_key and gemini_api_key from the user_profiles table and stores them in client-side state. These API keys are then accessible to any JavaScript code running in the page.

The updateApiKey function writes Claude and Gemini API keys directly to the Supabase 'user_profiles' table from client-side code. This means the API keys are transmitted over the network and stored in the database, but the client-side write operation also exposes the write path to potential abuse. If the Supabase Row Level Security (RLS) policy is misconfigured, an attacker could overwrite another user's API keys.

**Perspective 1:** The updateApiKey function sends API keys (claude, gemini) to the database from client-side code. The keys are transmitted over the network and stored in the database, potentially visible in Supabase logs. **Perspective 2:** The claude_api_key and gemini_api_key fields appear to be stored as plaintext in the user_profiles table. If the database is compromised, all user API keys would be exposed.

**Perspective 1:** In the getUserIdFromRequest function, when SUPABASE_SECRET_KEY is missing, the raw JWT token is accepted as the user ID without validation. This allows token forgery in development environments. **Perspective 2:** The getUserFromRequest function uses the public anon key (NEXT_PUBLIC_SUPABASE_PUBLISHABLE_DEFAULT_KEY) to validate tokens, which is less secure than using the service role key for server-side validation.

**Perspective 1:** console.log logs the user's email address on successful authentication. This exposes PII to browser extensions, error monitoring, and server-side logs if the code runs in a server context. **Perspective 2:** console.warn logs the error message from Supabase auth.getUser, which may contain token validation details. This could expose information about the authentication process.

The auth.ts file uses NEXT_PUBLIC_SUPABASE_PUBLISHABLE_DEFAULT_KEY (the anon/public key) to validate JWT tokens. The anon key cannot properly verify Supabase JWTs — it only allows basic client operations. Token validation should use the service role key on the server side. Using the anon key for validation provides no real security and may give a false sense of authentication.

**Perspective 1:** The getUserFromRequest function uses the public anon key (NEXT_PUBLIC_SUPABASE_PUBLISHABLE_DEFAULT_KEY) to validate JWT tokens. While this works for basic token validation, it relies on the client-side key which has limited permissions and may not be suitable for server-side authentication in a containerized environment. **Perspective 2:** The getUserFromRequest function does not explicitly check token expiration. While Supabase's getUser method should handle this, there's no fallback or explicit validation of the token's expiration claim (exp). In a containerized environment, expired tokens could potentially be used if there's a bug in the Supabase client library.

The getUserFromRequest function uses NEXT_PUBLIC_SUPABASE_PUBLISHABLE_DEFAULT_KEY (the anon/publishable key) to validate JWT tokens. The anon key is designed for client-side use and may not have the necessary permissions to call auth.getUser(). This could lead to authentication failures or bypasses.

The `getUserFromRequest` function extracts a JWT token from the Authorization header and validates it with Supabase. If the token is malformed or contains malicious payload, it could potentially bypass authentication or lead to injection attacks.

The `getUserFromRequest` function uses `NEXT_PUBLIC_SUPABASE_PUBLISHABLE_DEFAULT_KEY` (the anon/public key) to verify the JWT. This key is designed to be public and cannot securely verify tokens server-side. The function claims to validate the user but uses the wrong key, making the validation unreliable. The service role key should be used instead.

**Perspective 1:** The `getUserFromRequest` function uses `NEXT_PUBLIC_SUPABASE_PUBLISHABLE_DEFAULT_KEY` (the anon/public key) to verify JWT tokens. The anon key is designed for client-side use and has limited privileges. Using it for server-side token verification may not properly validate the token's authenticity, especially if RLS policies are not configured correctly. **Perspective 2:** The frontend uses the Supabase anon/public key to verify JWT tokens. The anon key cannot properly verify tokens server-side. This means token verification is ineffective and any JWT could be accepted. **Perspective 3:** The frontend uses the Supabase anon/public key for token verification. While this is appropriate for client-side operations, the code appears to be attempting server-side token verification with the wrong key. The anon key cannot verify tokens properly and may lead to authentication bypasses.

The 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 does not have the authority to verify tokens server-side. The verification may succeed but relies on the client-side key, which is a security anti-pattern.

**Perspective 1:** 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 permissions. For server-side token validation, the service role key should be used to ensure proper authorization checks. **Perspective 2:** The Supabase anon/public key is used for token verification instead of the service role key. This is a security misconfiguration that can lead to privilege escalation.

The `getUserFromRequest` function uses `NEXT_PUBLIC_SUPABASE_PUBLISHABLE_DEFAULT_KEY` (the anon/public key) to verify JWT tokens. The anon key is designed for client-side use and has RLS enforced. Using it server-side for token verification is unusual and may indicate a misconfiguration. More critically, if this key is exposed and the Supabase project has RLS policies that allow public access, token verification could be bypassed.

The frontend storage module imports and uses @aws-sdk/client-s3 with R2 credentials (R2_ACCESS_KEY_ID, R2_SECRET_ACCESS_KEY) read from environment variables. If these environment variables are exposed to the client-side bundle (e.g., via NEXT_PUBLIC_ prefix), the credentials would be visible in the browser's JavaScript source. Even if they are server-side only, the presence of this code in the frontend suggests a design flaw where storage operations may be performed client-side.

The SUPABASE_SECRET_KEY (service role key) is imported and used in a frontend file (supabase-server.ts). If this file is bundled and sent to the browser, the service role key would be exposed to all users, allowing full database access. The key is also potentially logged or exposed in error messages.

The file frontend/src/lib/supabase-server.ts imports and uses SUPABASE_SECRET_KEY (the service role key) in what appears to be frontend code. If this file is bundled into the client-side JavaScript, the service role key would be exposed to all users, granting full database access. The file is named 'supabase-server.ts' but lives under src/lib/ which may be included in the client bundle.

The supabase-server.ts file contains a function that creates a Supabase client using the service role key (SUPABASE_SECRET_KEY). This file is in the frontend directory and could potentially be exposed to clients. The service role key bypasses Row Level Security (RLS) and provides full access to the database.

The createServerSupabase function uses the SUPABASE_SECRET_KEY (service role key) which bypasses Row-Level Security. This file is in the frontend directory and could potentially be exposed to clients. The service role key should only be used in secure backend environments.

**Perspective 1:** The `getUserIdFromRequest` function extracts a JWT token from the Authorization header and validates it with Supabase. If the token is malformed or contains malicious payload, it could potentially bypass authentication or lead to injection attacks. **Perspective 2:** The `getUserIdFromRequest` function has a dev fallback that accepts the raw token as the user ID if Supabase URL or service key is missing. This could allow an attacker to bypass authentication in development environments.

When SUPABASE_URL or SUPABASE_SECRET_KEY are not set, the function returns the raw token string as the user ID. This means in development any string can be used as a user ID, bypassing all authentication.

When the Authorization header is missing, the error response explicitly states 'Missing or invalid Authorization header'. This reveals to attackers that Bearer token authentication is required, helping them understand the authentication mechanism.

The function getUserIdFromRequest() uses the service role key to verify Supabase JWT tokens. This function is in client-side code and could be imported and executed in the browser, exposing the service role key.

The `getUserIdFromRequest` function has a dev fallback that accepts the raw token string as the user ID when Supabase URL or service key is missing. This means in development, any token (or even a raw user ID string) is accepted as valid, completely bypassing authentication. The comment says 'Dev fallback' but this is a security bypass that could easily be deployed accidentally.

**Perspective 1:** When SUPABASE_URL or SUPABASE_SECRET_KEY are not set, the function falls back to accepting the raw token as the user ID. This bypasses all JWT validation and allows any token string to be treated as a valid user ID, completely breaking authentication in development or misconfigured environments. **Perspective 2:** The code falls back to a hardcoded service role key and URL when environment variables are not set, with a comment indicating this is for 'dev mode'. This means any deployment without proper environment variables will use insecure defaults, potentially exposing the Supabase service role key which has admin privileges. **Perspective 3:** A hardcoded fallback user ID and email are used when SUPABASE_SERVICE_KEY is not set. This bypasses authentication in development and could be exploited if deployed with this fallback.

When SUPABASE_URL or SUPABASE_SECRET_KEY are not set, the getUserIdFromRequest function returns the raw token string as the user ID without any validation. In production misconfiguration scenarios, this means any string passed as a Bearer token would be accepted as a valid user ID, completely bypassing authentication.

When SUPABASE_SECRET_KEY is not set, the function falls back to accepting the raw token as the user ID without any validation. This means in development, any token (including malicious ones) would be accepted as a valid user ID, potentially allowing unauthorized database access.

When SUPABASE_SECRET_KEY is not set, the function getUserIdFromRequest returns the raw token string as the user ID without any validation. This means any token (including arbitrary strings) would be accepted as a valid user ID in development, bypassing authentication entirely.

The getUserIdFromRequest function has a dev fallback that accepts a raw token as the user ID when Supabase URL or service key is not configured. This bypasses all authentication and could allow an attacker to impersonate any user in development environments that might accidentally be exposed.

When SUPABASE_URL or SUPABASE_SECRET_KEY are not configured, the getUserIdFromRequest function accepts the raw token as the user ID without any validation. This means in development mode, any token is accepted as valid, which could lead to authentication bypass.

When Supabase URL or service key is not configured, the function falls back to accepting the raw token as the user ID. If this code path is ever triggered in production (e.g., misconfiguration), it completely bypasses authentication and allows arbitrary user impersonation.

The function `getUserIdFromRequest` has a dev fallback that accepts the raw token as the user ID without any validation. This means in development mode, any string passed as a Bearer token will be treated as a valid user ID, completely bypassing authentication.

When SUPABASE_SECRET_KEY is not set, the function falls back to accepting the raw token string as the user ID. This means in development, any token (even an invalid one) is accepted, and the token string itself is used as the user ID. This could lead to privilege escalation or impersonation.

Cross-chunk interaction detected. This finding interacts with confirmed threat [0] via config. Interaction chain: No audit logging means tenant isolation violations (CONFIRMED-0) cannot be detected or traced after exploitation Original finding: **Perspective 1:** The schema does not include any audit logging tables or soft delete columns (e.g., deleted_at). This makes it difficult to track data access, modifications, or recover from accidental deletions. **Perspective 2:** The schema does not configure any connection pooling limits or timeouts. Without proper configuration, the database could be overwhelmed by too many concurrent connections. **Perspective 3:** Row Level Security (RLS) is only enabled on the user_profiles table. Othe

Cross-chunk interaction detected. This finding interacts with confirmed threat [9] via config. Interaction chain: No token expiration (CANDIDATE-375) means forged download tokens (CONFIRMED-9) remain valid indefinitely, enabling persistent unauthorized access Original finding: Download tokens are signed with HMAC-SHA256 but have no expiration time or revocation mechanism. Once a token is generated, it remains valid indefinitely. If a token is leaked, it can be used to download files without any time limit.

Cross-chunk interaction detected. This finding interacts with confirmed threat [9] via config. Interaction chain: Missing audit trail for download token verification (CANDIDATE-376) means exploitation of CONFIRMED-9 cannot be detected Original finding: The verifyDownload function returns null on failure but does not log any audit event. Failed download attempts (invalid tokens, expired tokens) are not recorded, making it impossible to detect brute-force attacks on download tokens or unauthorized access attempts.

Cross-chunk interaction detected. This finding interacts with confirmed threat [9] via data_flow. Interaction chain: Non-constant-time HMAC comparison (CANDIDATE-379) enables timing attacks to brute-force download tokens (CONFIRMED-9) Original finding: The timingSafeEqStr function compares the length of two strings before calling crypto.timingSafeEqual. If the lengths differ, it returns false early, leaking the length of the expected signature via timing. While the impact is limited because the signature length is fixed, this is still a deviation from best practices for constant-time comparison.

Cross-chunk interaction detected. This finding interacts with confirmed threat [6] via data_flow. Interaction chain: Error messages leaking internal state (CANDIDATE-394) combined with auth middleware using service role key (CONFIRMED-6) reveals server configuration to attackers Original finding: The getUserIdFromRequest function throws Response objects with messages like 'Missing or invalid Authorization header', 'Server auth is not configured', and 'Invalid or expired token'. These messages leak information about the server's authentication configuration and can be used for enumeration.

Cross-chunk interaction detected. This finding interacts with confirmed threat [12] via data_flow. Interaction chain: No file type validation on upload (CANDIDATE-395) combined with mass data exfiltration via tabular API (CONFIRMED-12) allows uploading malicious files for processing Original finding: **Perspective 1:** The multer upload configuration accepts files without validating MIME types or file signatures. While the accept attribute on the frontend input limits file selection, server-side validation is missing, allowing any file type to be uploaded if the request is crafted directly. **Perspective 2:** The file upload handler does not validate the actual content type of uploaded files against their declared extension. An attacker could upload a malicious file with a .pdf or .docx ext

Cross-chunk interaction detected. This finding interacts with confirmed threat [12] via data_flow. Interaction chain: Arbitrary file upload without content validation (CANDIDATE-397) combined with tabular review API (CONFIRMED-12) enables processing of malicious documents Original finding: The upload handler accepts files with extensions .pdf, .docx, and .doc, but there is no server-side validation of the actual file content. A malicious file with a benign extension could be uploaded and later processed by LibreOffice or other components.

Cross-chunk interaction detected. This finding interacts with confirmed threat [12] via data_flow. Interaction chain: No file type validation (CANDIDATE-398) combined with tabular review API (CONFIRMED-12) allows uploading executable content for processing Original finding: **Perspective 1:** The upload handler only checks file size, not file type. An attacker could upload executable files, scripts, or other dangerous content. The accept attribute on the client-side input is easily bypassed. **Perspective 2:** Uploaded files are stored directly without any malware scanning. An attacker could upload a malicious document containing macros or exploits.

Cross-chunk interaction detected. This finding interacts with confirmed threat [12] via data_flow. Interaction chain: No file type validation in upload middleware (CANDIDATE-399) combined with tabular review API (CONFIRMED-12) enables arbitrary file processing Original finding: The multer upload middleware only limits file size but does not validate file type, MIME type, or file extension. Any file type can be uploaded.

Cross-chunk interaction detected. This finding interacts with confirmed threat [12] via data_flow. Interaction chain: No server-side file type validation (CANDIDATE-400) combined with tabular review API (CONFIRMED-12) allows processing of malicious uploads Original finding: **Perspective 1:** The multer configuration does not validate the MIME type or file extension of uploaded files. The frontend restricts to .pdf, .docx, and .doc files, but this can be bypassed by sending requests directly to the API. An attacker could upload arbitrary file types, potentially leading to stored XSS or other attacks if files are served back to users. **Perspective 2:** The upload handler does not validate file content type (MIME type magic bytes) server-side. It only checks the fi

Cross-chunk interaction detected. This finding interacts with confirmed threat [6] via config. Interaction chain: No rate limiting on auth middleware (CANDIDATE-404) combined with service role key usage (CONFIRMED-6) enables brute-force attacks on authentication Original finding: The authentication middleware does not implement rate limiting. In a containerized environment, this could allow attackers to perform brute-force attacks against the authentication endpoint without restriction, potentially overwhelming the container.

Cross-chunk interaction detected. This finding interacts with confirmed threat [6] via config. Interaction chain: No rate limiting on auth middleware (CANDIDATE-405) combined with service role key usage (CONFIRMED-6) enables brute-force attacks on authentication Original finding: The authentication middleware does not implement any rate limiting or request throttling. This could allow attackers to perform brute force attacks on the authentication endpoint.

Cross-chunk interaction detected. This finding interacts with confirmed threat [6] via data_flow. Interaction chain: No explicit token expiration validation (CANDIDATE-409) combined with auth middleware using service role key (CONFIRMED-6) allows use of expired tokens Original finding: The middleware calls admin.auth.getUser(token) which validates the token but does not explicitly check for token expiration or revocation. While Supabase handles expiration internally, there is no additional validation such as checking if the user's session has been explicitly revoked or if the user account is disabled.

Cross-chunk interaction detected. This finding interacts with confirmed threat [6] via data_flow. Interaction chain: User email stored without verification (CANDIDATE-410) combined with auth middleware (CONFIRMED-6) enables email spoofing in downstream access checks Original finding: The user's email is extracted from the token and stored in res.locals.userEmail after being lowercased. However, the email is not verified to belong to the user - it's taken directly from the JWT claim. If the token is valid but contains an incorrect email (e.g., from a compromised provider), this could lead to authorization bypasses in downstream code that relies on email-based access control.

Cross-chunk interaction detected. This finding interacts with confirmed threat [7] via data_flow. Interaction chain: Resource existence leaked via 404 (CANDIDATE-411) combined with unbounded LLM calls (CONFIRMED-7) helps attackers enumerate valid chat IDs for cost attacks Original finding: When a chat is not found or the user doesn't have access, a 404 status is returned. This allows attackers to distinguish between 'chat does not exist' and 'chat exists but you don't have access' by observing timing or other side channels. The same 404 is returned for both cases, but the code path differs slightly.

Cross-chunk interaction detected. This finding interacts with confirmed threat [7] via data_flow. Interaction chain: Title generation allows unauthorized LLM calls (CANDIDATE-413) combined with unbounded LLM calls (CONFIRMED-7) creates additional cost attack vector Original finding: **Perspective 1:** The POST /chat/:chatId/generate-title endpoint allows any project member to trigger an LLM call to generate a chat title. While the title generation itself is low-risk, it confirms chat existence and allows unauthorized users to consume API resources (LLM credits) on behalf of the project owner. **Perspective 2:** The generate-title endpoint only checks project access, not chat ownership. A shared project member can trigger title generation on any chat in the project, even ch

Cross-chunk interaction detected. This finding interacts with confirmed threat [7] via config. Interaction chain: No rate limiting on title generation (CANDIDATE-414) combined with unbounded LLM calls (CONFIRMED-7) enables cost escalation via title generation Original finding: The POST /chat/:chatId/generate-title endpoint calls an external LLM API to generate a chat title. There is no rate limiting on this endpoint, which could be abused to incur excessive costs or perform denial-of-service attacks against the LLM provider.

Cross-chunk interaction detected. This finding interacts with confirmed threat [7] via data_flow. Interaction chain: Resource existence leaked via 404 in title generation (CANDIDATE-415) combined with unbounded LLM calls (CONFIRMED-7) aids attack enumeration Original finding: When generating a title, if the chat is not found or the user doesn't have access, a 404 is returned. This allows attackers to distinguish between 'chat does not exist' and 'chat exists but you don't have access'.

**Perspective 1:** The schema does not include any audit logging tables or soft delete columns (e.g., deleted_at). This makes it difficult to track data access, modifications, or recover from accidental deletions. **Perspective 2:** The schema does not configure any connection pooling limits or timeouts. Without proper configuration, the database could be overwhelmed by too many concurrent connections. **Perspective 3:** Row Level Security (RLS) is only enabled on the user_profiles table. Other tables like projects, documents, chats, and workflows do not have RLS policies defined in this migration, meaning they rely on application-level authorization only.

The user_profiles table schema defines claude_api_key and gemini_api_key as plain text columns. These columns store user-provided API keys without any encryption or hashing. If the database is compromised, all user API keys are exposed.

**Perspective 1:** The nixpacks.toml installs LibreOffice via nixPkgs. This adds a large, complex dependency to the production container image, increasing the attack surface. LibreOffice has had numerous CVEs for remote code execution, buffer overflows, and file parsing vulnerabilities. If the container is compromised, an attacker could leverage LibreOffice for privilege escalation or lateral movement. **Perspective 2:** LibreOffice is installed in the production container image. This increases the attack surface and image size. LibreOffice is a complex application with a large codebase and potential vulnerabilities. It should be isolated or the container should run with minimal privileges.

The package-lock.json does not include provenance information (e.g., 'npm provenance' attestations) for dependencies. Without provenance, it is impossible to verify the origin and build process of third-party packages, increasing the risk of using compromised or malicious packages.

Express.js by default sets the X-Powered-By header, revealing the technology stack (Express) to attackers. This helps attackers fingerprint the application and target Express-specific vulnerabilities.

The CORS origin is set from the FRONTEND_URL environment variable. If an attacker can control this environment variable, they could bypass CORS restrictions and make cross-origin requests to the API.

**Perspective 1:** The CORS configuration uses `origin: process.env.FRONTEND_URL ?? 'http://localhost:3000'` with `credentials: true`. This is a single-origin allowlist, which is better than a wildcard, but the configuration does not validate the Host header or reject requests with unexpected origins. If the FRONTEND_URL env var is misconfigured or defaults to localhost in production, it could allow cross-origin requests from unintended origins. **Perspective 2:** The CORS origin pattern uses a regex that matches any subdomain of the configured origin (e.g., 'https://evil-origin.com' would match if the pattern is 'https://*.origin.com'). This broad matching could allow unauthorized origins to make cross-origin requests. **Perspective 3:** The CORS origin pattern uses a regex that matches any subdomain of the configured origin (e.g., '*.example.com'). If the environment variable is not set or is set to a permissive value, this could allow arbitrary origins to make cross-origin requests. The pattern also doesn't validate the TLD structure, potentially allowing origins like 'evil-example.com' to match if the regex is too broad. **Perspective 4:** The Express application does not validate the Host header of incoming requests. This could allow host header injection attacks, which can be used to poison caching, password reset emails, or SSRF protections. While the application doesn't use the Host header directly in responses, it's a defense-in-depth measure.

**Perspective 1:** CORS is configured with a single origin from environment variable, falling back to 'http://localhost:3000'. While not fully permissive, the fallback to localhost in production could allow local network attacks. Additionally, credentials are enabled, which could expose cookies/tokens to unauthorized origins if the FRONTEND_URL is misconfigured. **Perspective 2:** The CORS configuration allows all origins (origin: '*') in production. This permits any website to make cross-origin requests to the API, which could lead to CSRF-like attacks if the API relies on cookie-based authentication or exposes sensitive data. While the API uses Bearer tokens, permissive CORS still increases the attack surface.

**Perspective 1:** The Express application does not implement any rate limiting middleware. This exposes API endpoints to brute-force attacks, credential stuffing, and denial-of-service attacks. While rate limiting is often handled at a reverse proxy level, the application should have defense-in-depth rate limiting for critical endpoints like authentication and chat. **Perspective 2:** The application does not implement any rate limiting middleware. This leaves all endpoints vulnerable to brute-force attacks, credential stuffing, and denial-of-service via excessive requests. **Perspective 3:** The Express application does not implement any rate limiting middleware. Without rate limiting, the API is vulnerable to brute-force attacks, DoS attacks, and abuse of endpoints like chat, authentication, and file uploads. Rate limiting should be applied at the edge/gateway level.

The /health endpoint is publicly accessible without any authentication. While this is common for health checks, it reveals that the server is running and responding, which aids attackers in reconnaissance.

The `checkProjectAccess` function compares user emails against `shared_with` arrays using case-insensitive comparison. However, email normalization (trimming, Unicode normalization) is not applied, which could lead to bypasses if emails are stored with different casing or Unicode variations.

The checkProjectAccess function fetches the project and then checks ownership or shared access. If the project's shared_with list is updated between the fetch and the check, there could be a race condition. However, this is a low-risk issue in most applications.

**Perspective 1:** The shared_with email comparison uses .toLowerCase() which is case-insensitive but does not normalize Unicode characters. Attackers could register emails with Unicode homoglyphs (e.g., using a Cyrillic 'е' instead of Latin 'e') to bypass the email comparison and gain unauthorized access to projects. **Perspective 2:** The shared_with check compares emails directly without verifying domain ownership or email deliverability. If an attacker can create an account with an email that is a substring of a shared email (e.g., 'user@example.com' vs 'user@example.com.evil.com'), they might gain unauthorized access depending on how the comparison is implemented elsewhere.

The listAccessibleProjectIds function returns all project IDs the user can access. If this function is used in an endpoint that returns project IDs to the client, it could expose the existence of projects that the user has access to but may not be aware of. This is generally acceptable for authorized users but should be considered in the context of data minimization.

**Perspective 1:** The `AssistantWorkflowModal` component renders user-controlled workflow prompt content using `ReactMarkdown`. If the prompt contains malicious markdown or HTML, it could lead to XSS or other injection attacks. **Perspective 2:** The `loadCurrentVersionBytes` function constructs a database query using a user-controlled `documentId`. If the database is a NoSQL database like MongoDB, this could lead to NoSQL injection. **Perspective 3:** The `generateDocx` function constructs a filename from user-controlled `title` input. If this filename is later used in a shell command (e.g., for file conversion), it could lead to command injection. **Perspective 4:** The `enrichWithPriorEvents` function processes user-controlled data from chat messages. If this data is merged into objects without proper sanitization, it could lead to prototype pollution.

**Perspective 1:** Generated documents are uploaded to S3-compatible storage using uploadFile without any authenticated encryption (e.g., AES-GCM). The storage key is a predictable path derived from userId, docId, and filename. An attacker with storage access could read or tamper with documents without detection. **Perspective 2:** Edited documents (via edit_document) are uploaded to storage using uploadFile without authenticated encryption. The storage path is predictable (documents/{userId}/{documentId}/edits/{versionId}.docx). An attacker with storage access could tamper with edited documents. **Perspective 3:** Document IDs are generated using crypto.randomUUID().replace(/-/g, '') which removes hyphens from a UUID v4. While UUID v4 uses 122 random bits, the hyphens are structural and removing them doesn't reduce entropy. However, the resulting string is used as part of storage paths, and the randomness source (crypto.randomUUID) is cryptographically secure. This is acceptable but worth noting for audit purposes. **Perspective 4:** Documents are stored in S3-compatible storage without client-side encryption. While S3 provides server-side encryption, the application does not implement any additional encryption layer. Sensitive legal documents could be exposed if storage credentials are compromised. **Perspective 5:** When downloading documents via getDocumentUrl, the application returns a presigned URL without any content hash or signature verification. There is no mechanism to verify that the downloaded content hasn't been tampered with in transit or at rest.

**Perspective 1:** The libreoffice-convert package is imported dynamically without a pinned version in the import statement. This could lead to unexpected behavior or security issues if a malicious version is published. The package itself is a wrapper around a system binary and may have known vulnerabilities. **Perspective 2:** The application relies on LibreOffice being installed on the system for DOCX-to-PDF conversion. This is a heavy system dependency that may not be available in all environments and could introduce security vulnerabilities if the LibreOffice version is outdated. **Perspective 3:** The jszip package is imported without a pinned version. This could lead to unexpected behavior or security issues if a malicious version is published.

**Perspective 1:** The docxToPdf function uses LibreOffice for document conversion without any sandboxing or resource limits. LibreOffice has a history of vulnerabilities, and running it without isolation could allow arbitrary code execution through malicious documents. **Perspective 2:** The LibreOffice conversion service is configured without any restrictions on file size, document complexity, or concurrent conversions. This could be exploited for denial-of-service attacks by submitting large or complex documents that consume excessive server resources during conversion. **Perspective 3:** The LibreOffice conversion service is called without any restrictions on file size, type, or number of concurrent conversions. This could be abused for resource exhaustion.

The docx-to-pdf conversion relies on a system-installed LibreOffice binary via libreoffice-convert. There is no verification of the LibreOffice binary integrity, no pinned version, and no containerized environment to ensure reproducible builds. A compromised or outdated LibreOffice installation could produce malicious PDFs or leak document contents.

The `normalizeDocxZipPaths` function processes DOCX files (which are ZIP archives containing XML). If the DOCX contains malicious XML with external entities, the JSZip library may not prevent XXE attacks when the XML is later parsed by LibreOffice or other tools.

The normalizeDocxZipPaths function processes arbitrary buffers as ZIP files without validation. A malicious buffer could exploit vulnerabilities in JSZip or cause excessive memory usage.

The `JSZip` import is used in `normalizeDocxZipPaths` but that function is never called anywhere in the codebase. The only exported function `docxToPdf` calls `normalizeDocxZipPaths` internally, but the import is at module level and the function is defined but never invoked from any route or handler. This suggests the conversion pipeline was planned but not wired up.

The normalizeDocxZipPaths function uses JSZip to parse potentially malicious DOCX files. While JSZip is generally safe, there is no validation of the ZIP structure, file count, or individual file sizes before processing. A maliciously crafted ZIP could cause resource exhaustion.

The code imports 'fast-xml-parser' and 'jszip' without any integrity check. These libraries are critical for parsing DOCX files and could be exploited if compromised. The package-lock.json provides some protection, but additional verification is recommended.

**Perspective 1:** The code uses JSON.parse on user-controlled data without sanitization, which could lead to prototype pollution if the parsed object contains __proto__ or constructor keys. **Perspective 2:** The code manipulates file paths using string replacement without proper sanitization, which could lead to path traversal or command injection if user input is involved.

The docxTrackedChanges module uses fast-xml-parser to parse DOCX XML files. While fast-xml-parser has some protections against XXE, the parser is configured with processEntities: true which could allow entity expansion attacks. An attacker could craft a malicious DOCX file with XML entities that cause denial of service or information disclosure when processed.

The constant `W_NS_ATTRS` is defined at line 1172 but never referenced in any function. It is exported as `_nsAttrs` with a comment saying 'kept for potential future use'. This is a dead code artifact — the namespace attributes are already inherited from the XML document root and don't need to be emitted manually.

The `getZipEntry` and `setZipEntry` functions handle file paths with backslash-to-forward-slash conversion but don't validate against path traversal attacks (e.g., `../` sequences).

**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 token forgery in production if environment variables are misconfigured. **Perspective 2:** Download tokens are HMAC-signed but have no expiration mechanism. Tokens stored in chat history remain valid indefinitely, increasing the risk window if a token is leaked.

The download token signing secret falls back to 'dev-secret' when DOWNLOAD_SIGNING_SECRET and SUPABASE_SECRET_KEY are not set. This is a weak secret that could be easily guessed, allowing attackers to forge download tokens.

**Perspective 1:** The download token signing mechanism falls back to 'dev-secret' when DOWNLOAD_SIGNING_SECRET and SUPABASE_SECRET_KEY are not set. In a production container environment, this weak secret could allow an attacker to forge download tokens and access any file stored in the system. **Perspective 2:** The download token signing uses a weak fallback secret. In a containerized environment, environment variables might be more accessible, making this a potential attack vector for forging download tokens.

Download tokens are signed with HMAC-SHA256 but have no expiration time or revocation mechanism. Once a token is generated, it remains valid indefinitely. If a token is leaked, it can be used to download files without any time limit.

The verifyDownload function returns null on failure but does not log any audit event. Failed download attempts (invalid tokens, expired tokens) are not recorded, making it impossible to detect brute-force attacks on download tokens or unauthorized access attempts.

**Perspective 1:** The signDownload function accepts arbitrary path and filename strings without validation. An attacker who can control these parameters could sign tokens for malicious paths or filenames. **Perspective 2:** The download signing secret falls back to 'dev-secret' if DOWNLOAD_SIGNING_SECRET and SUPABASE_SECRET_KEY are not set. This could allow token forgery in production if environment variables are misconfigured.

The project does not generate a Software Bill of Materials (SBOM) for its Node.js dependencies. Without an SBOM, there is no automated way to track known vulnerabilities in transitive dependencies, verify supply chain integrity, or meet compliance requirements. The package.json and package-lock.json exist but no SBOM tooling (e.g., CycloneDX, SPDX) is configured.

The timingSafeEqStr function compares the length of two strings before calling crypto.timingSafeEqual. If the lengths differ, it returns false early, leaking the length of the expected signature via timing. While the impact is limited because the signature length is fixed, this is still a deviation from best practices for constant-time comparison.

**Perspective 1:** The Claude streaming implementation logs every stream event to a file (claude-raw-stream.log) using fs.appendFile. This log file could contain sensitive information from LLM responses, including PII, API keys, or internal system instructions if the LLM is prompted to reveal them. **Perspective 2:** The Claude streaming code accepts tool call arguments (tu.input) from the LLM and passes them to runTools without validation against the declared tool schema. If the LLM produces malformed or unexpected arguments, it could cause errors or unexpected behavior in downstream tool execution.

The streamClaude function logs every stream event to a file at 'claude-raw-stream.log' using fs.appendFile. This log file may contain sensitive information including user prompts, document content, API responses, and potentially API keys if they appear in error messages.

**Perspective 1:** The model name is passed as a parameter to the Claude API without being validated against an allowlist. An attacker who can control the model parameter could potentially use an unintended model or one with different capabilities. **Perspective 2:** The model name is passed as a parameter to the Claude API call without being validated against an allowlist. If the model name originates from user input, an attacker could specify a different model that may have different behavior, pricing, or security properties. **Perspective 3:** The model name is passed as a parameter to the Claude SDK without being validated against an allowlist. An attacker who can control the model name could potentially specify a different model endpoint or a model with different capabilities than intended.

The Gemini API client falls back to GEMINI_API_KEY environment variable if no override is provided, but does not validate that the key is non-empty or properly formatted. An empty or malformed key could lead to authentication failures or unexpected behavior.

The Gemini API key falls back to process.env.GEMINI_API_KEY. If the API key is invalid or missing, error messages from the Google GenAI client may include the key or reveal that it's missing, aiding attackers in understanding the authentication setup.

**Perspective 1:** The model name is passed directly from the request parameters to the Gemini API call. If an attacker can control the model parameter, they could potentially redirect requests to a different model or a malicious endpoint. The model name should be validated against an allowlist. **Perspective 2:** The model name is passed as a parameter to the Gemini API without being validated against an allowlist. An attacker who can control the model parameter could potentially use an unintended model or one with different capabilities. **Perspective 3:** The model name is passed as a parameter to the Gemini API call without being validated against an allowlist. If the model name originates from user input, an attacker could specify a different model that may have different behavior, pricing, or security properties. **Perspective 4:** The model name is passed as a parameter to the Gemini SDK without being validated against an allowlist. This could allow an attacker to specify a different model endpoint or a model with different capabilities.

**Perspective 1:** The Gemini API response is consumed without any integrity check or signature verification. If the connection is compromised or the API endpoint is spoofed, the application would accept malicious model output without detection. **Perspective 2:** The application does not verify the integrity or authenticity of responses received from the Gemini API. A compromised network or DNS could serve malicious model responses without detection.

The streamGemini function has a maxIterations of 10, but each iteration can trigger additional tool calls and API requests. If the model repeatedly generates tool calls that the tool runner resolves, the loop can make up to 10 sequential API calls per user request. An attacker could craft prompts that force many tool call iterations, consuming API quota and increasing latency. While not a direct server crash, this can exhaust API rate limits and degrade service for other users.

The full Gemini API response chunk is logged to console with JSON.stringify, potentially exposing sensitive information including API response structures, model internals, and possibly user data or prompts in the response.

**Perspective 1:** Model identifiers like 'claude-opus-4-7', 'claude-sonnet-4-6', 'gemini-3.1-pro-preview', and 'gemini-3-flash-preview' are defined as plain strings with no mechanism to verify the integrity, provenance, or authenticity of the model artifacts they refer to. There is no hash pinning, no signature verification, and no way to detect if a model has been tampered with or swapped for a malicious version. An attacker who compromises the model registry or the API endpoint could serve a different model under the same identifier. **Perspective 2:** Model IDs are hardcoded as strings without any associated provenance metadata (e.g., revision hash, checksum, or source URL). This makes it impossible to verify which exact model version is being used or detect if the model has been tampered with. **Perspective 3:** Model IDs are defined as hardcoded strings without any associated provenance metadata such as base model hash, revision pinning, or integrity checksum. This means that if a model registry is compromised or a model is swapped at the same ID, the application would silently load the malicious model without detection. **Perspective 4:** Model identifiers (e.g., 'claude-sonnet-4-20250514', 'gemini-2.5-flash-preview-04-17') are hardcoded as strings. There is no mechanism to verify that these identifiers correspond to authentic, untampered models from the provider. If a provider's model registry is compromised or a model is deprecated and replaced with a malicious version, the application would automatically load the compromised model without any integrity check. **Perspective 5:** The code does not check or enforce any license restrictions on the models being used. Models like Claude and Gemini have specific terms of service that may restrict commercial use, redistribution, or fine-tuning. There is no mechanism to ensure that the application's use case is compliant with the model's license.

The storage module reads R2 credentials (R2_ACCESS_KEY_ID, R2_SECRET_ACCESS_KEY) from environment variables but does not validate that they are present before use. If these environment variables are missing or misconfigured, the S3 client will fail with a cryptic error. More importantly, there is no warning or fallback mechanism if credentials are invalid or expired.

Documents stored in Cloudflare R2 are not encrypted client-side before upload. The code uploads raw file content (ArrayBuffer) directly to S3-compatible storage without any application-level encryption. While R2 provides server-side encryption at rest, this does not protect against access by the storage provider or in case of misconfigured bucket policies. Legal documents containing sensitive information should be encrypted client-side before being sent to object storage.

The `storageKey()` and related functions construct S3 storage keys using user-provided filenames. While the `storageExtension()` function validates the extension, the filename itself is not sanitized for path traversal characters (e.g., '../', null bytes).

The code imports '@supabase/supabase-js' without any integrity check. If the package is compromised, it could leak credentials or manipulate database queries. The package-lock.json provides some protection, but additional verification is recommended.

The getUserIdFromRequest function throws Response objects with messages like 'Missing or invalid Authorization header', 'Server auth is not configured', and 'Invalid or expired token'. These messages leak information about the server's authentication configuration and can be used for enumeration.

**Perspective 1:** The multer upload configuration accepts files without validating MIME types or file signatures. While the accept attribute on the frontend input limits file selection, server-side validation is missing, allowing any file type to be uploaded if the request is crafted directly. **Perspective 2:** The file upload handler does not validate the actual content type of uploaded files against their declared extension. An attacker could upload a malicious file with a .pdf or .docx extension that contains executable code, which could then be served to users or processed by the server. **Perspective 3:** The upload handler does not validate the file type against the MIME type or magic bytes. It only checks the file extension, which can be easily spoofed.

The upload handler accepts files without computing or verifying any content hash (SHA-256, etc.). This means there is no way to verify file integrity after upload, detect corruption, or prove that a downloaded file matches what was originally uploaded. This also prevents establishing a chain of custody for legal documents.

The upload handler accepts files with extensions .pdf, .docx, and .doc, but there is no server-side validation of the actual file content. A malicious file with a benign extension could be uploaded and later processed by LibreOffice or other components.

**Perspective 1:** The upload handler only checks file size, not file type. An attacker could upload executable files, scripts, or other dangerous content. The accept attribute on the client-side input is easily bypassed. **Perspective 2:** Uploaded files are stored directly without any malware scanning. An attacker could upload a malicious document containing macros or exploits.

The multer upload middleware only limits file size but does not validate file type, MIME type, or file extension. Any file type can be uploaded.

**Perspective 1:** The multer configuration does not validate the MIME type or file extension of uploaded files. The frontend restricts to .pdf, .docx, and .doc files, but this can be bypassed by sending requests directly to the API. An attacker could upload arbitrary file types, potentially leading to stored XSS or other attacks if files are served back to users. **Perspective 2:** The upload handler does not validate file content type (MIME type magic bytes) server-side. It only checks the file extension on the client side. An attacker could upload a malicious file with a .pdf extension but containing executable content. **Perspective 3:** The upload handler accepts files based solely on the 'accept' attribute in the frontend HTML, which is client-side only. There is no server-side validation of file types using magic bytes or MIME type checking. An attacker can upload arbitrary file types (e.g., executable scripts, HTML with JavaScript) by simply changing the file extension.

User model settings (including tabular_model and API keys) are loaded from the user_profiles table without validation that the model names are valid or that the API keys are not compromised. An attacker who gains access to the database could modify these settings to use a different model or a compromised API key.

**Perspective 1:** User API keys (claude_api_key, gemini_api_key) are stored in plaintext in the user_profiles table. If the database is compromised, all user API keys would be exposed. These keys provide access to third-party AI services and could be used for unauthorized usage. **Perspective 2:** The getUserModelSettings function retrieves API keys from the database without validating that they are still valid or have the required permissions. Stale or invalid keys could cause silent failures. **Perspective 3:** The system does not provide a mechanism for users to rotate their API keys. If a key is compromised, the user must manually generate a new key from the provider and update it in the settings. **Perspective 4:** User API keys are stored without any scope or permission information. The system uses whatever permissions the key has from the provider, with no way to restrict what the key can do within the application.

The auth middleware uses the Supabase service role key (SUPABASE_SECRET_KEY) to verify user tokens via admin.auth.getUser(token). While this works, it uses the admin client with full database access privileges. A more secure approach would be to verify the JWT signature locally using the Supabase JWT secret, avoiding the need for the service role key in the auth path.

The authentication middleware does not implement rate limiting. In a containerized environment, this could allow attackers to perform brute-force attacks against the authentication endpoint without restriction, potentially overwhelming the container.

The authentication middleware does not implement any rate limiting or request throttling. This could allow attackers to perform brute force attacks on the authentication endpoint.

**Perspective 1:** The requireAuth middleware uses the SUPABASE_SECRET_KEY (service role key) to verify user tokens via admin.auth.getUser(). While this works, it uses a privileged key that has full access to all Supabase resources. A compromise of this key would be catastrophic. The service key should not be used in request-scoped middleware if a more restricted approach is possible. **Perspective 2:** The auth middleware only checks if the token is valid via Supabase's getUser(). It does not check if the token has been explicitly revoked (e.g., user logout, password change, admin action). Supabase JWT tokens remain valid until they expire unless explicitly revoked. **Perspective 3:** The auth middleware does not implement rate limiting on authentication failures. An attacker could rapidly try different tokens or Authorization headers without being throttled, enabling brute-force attacks against the API. **Perspective 4:** The auth middleware does not log authentication failures. Without logging, it is difficult to detect and investigate brute-force attacks, credential stuffing, or other authentication anomalies.

The application does not validate the Host header against a whitelist of allowed domains. This enables Host header injection attacks, which can be used to poison password reset links, cache poisoning, or SSRF via open redirects. The backend should reject requests with unexpected Host headers at the edge.

The auth middleware checks for empty SUPABASE_URL or SUPABASE_SECRET_KEY at request time, returning a 500 error. This means the application starts successfully even without critical secrets configured, potentially exposing unauthenticated endpoints or leaking stack traces before the first authenticated request.

The middleware calls admin.auth.getUser(token) which validates the token but does not explicitly check for token expiration or revocation. While Supabase handles expiration internally, there is no additional validation such as checking if the user's session has been explicitly revoked or if the user account is disabled.

The user's email is extracted from the token and stored in res.locals.userEmail after being lowercased. However, the email is not verified to belong to the user - it's taken directly from the JWT claim. If the token is valid but contains an incorrect email (e.g., from a compromised provider), this could lead to authorization bypasses in downstream code that relies on email-based access control.

When a chat is not found or the user doesn't have access, a 404 status is returned. This allows attackers to distinguish between 'chat does not exist' and 'chat exists but you don't have access' by observing timing or other side channels. The same 404 is returned for both cases, but the code path differs slightly.

The GET /chat/:chatId endpoint returns all fields from the chat_messages table without filtering. This could expose internal fields such as internal IDs, timestamps, or other metadata that may not be necessary for the client. The response should be limited to only the fields required by the frontend.

**Perspective 1:** The POST /chat/:chatId/generate-title endpoint allows any project member to trigger an LLM call to generate a chat title. While the title generation itself is low-risk, it confirms chat existence and allows unauthorized users to consume API resources (LLM credits) on behalf of the project owner. **Perspective 2:** The generate-title endpoint only checks project access, not chat ownership. A shared project member can trigger title generation on any chat in the project, even chats they don't own. This leaks the chat's existence and allows resource consumption.

The POST /chat/:chatId/generate-title endpoint calls an external LLM API to generate a chat title. There is no rate limiting on this endpoint, which could be abused to incur excessive costs or perform denial-of-service attacks against the LLM provider.

When generating a title, if the chat is not found or the user doesn't have access, a 404 is returned. This allows attackers to distinguish between 'chat does not exist' and 'chat exists but you don't have access'.

The generate-title endpoint logs the full error object to the console when title generation fails. This could expose internal implementation details.

The chat streaming endpoint logs the incoming request details including userId, chat_id, project_id, and model. While this is useful for debugging, it could expose sensitive information in production logs. The message count is also logged, but the actual message content is not.

The chat streaming endpoint logs userId, chat_id, project_id, model, and message count to the console. While this is server-side logging, it exposes internal identifiers and usage patterns that could be useful to an attacker with access to logs.

When posting to a chat, if the chat is not found or the user doesn't have access, the chatId is set to null and a new chat is created. This behavior differs from returning a 404, potentially leaking information about chat existence.

The chat streaming endpoint logs apiMessageCount, docCount, and workflowCount to the console. This exposes internal processing details about how many documents and workflows are being used.

The chat streaming endpoint logs fullTextLen and eventCount after LLM stream completion. This exposes the size of generated content and number of events, which could be used to infer processing patterns.

The chat streaming endpoint logs the full error object to the console on stream errors. This could expose internal implementation details, stack traces, and potentially sensitive data.

**Perspective 1:** The document upload and download endpoints use raw storage without any authenticated encryption. Documents are stored as plain bytes in the storage backend (R2/S3). An attacker with storage access could read or tamper with documents without detection. There is no integrity verification (e.g., HMAC, digital signature) on stored documents. **Perspective 2:** The code downloads document bytes from storage and serves them directly to clients. While HTTPS protects the client-server channel, there is no end-to-end encryption or content encryption key management. If the storage backend is compromised or misconfigured, document content is exposed. **Perspective 3:** The code uses crypto.randomUUID() to generate version slugs for document storage paths. While this provides sufficient uniqueness, it does not provide cryptographic guarantees for security-critical operations. For storage path generation, this is acceptable but should not be used for security tokens or secrets. **Perspective 4:** The code imports and uses external libraries (pdfjs-dist, mammoth, jszip) but does not implement certificate pinning for any HTTPS connections. While not directly exploitable in this code, it's a defense-in-depth concern for any external API calls the application makes.

**Perspective 1:** Document upload, delete, version creation, and edit resolution operations lack audit logging. There is no record of who performed what action on which document, when, or the result. This makes forensic investigation of unauthorized document access or data loss impossible. **Perspective 2:** Document download and display endpoints (GET /single-documents/:documentId/display, GET /single-documents/:documentId/url, GET /single-documents/:documentId/docx) do not log access events. There is no record of which user accessed which document, when, or from which IP. This is a compliance gap for sensitive legal documents. **Perspective 3:** Document version creation (POST /:documentId/versions), renaming (PATCH /:documentId/versions/:versionId), and listing (GET /:documentId/versions) lack audit logging. There is no record of who created or renamed a version, making it impossible to track unauthorized version changes. **Perspective 4:** Edit accept/reject operations (POST /:documentId/edits/:editId/accept and /reject) lack audit logging. While console.log statements exist for debugging, there is no persistent audit record of who accepted or rejected a tracked change, when, or the outcome. **Perspective 5:** The bulk document download endpoint (POST /single-documents/download-zip) does not log which documents were downloaded by which user. This is a significant compliance gap for bulk data access. **Perspective 6:** The tracked change IDs endpoint (GET /:documentId/tracked-change-ids) does not log access. While less sensitive than document content, access patterns could reveal user behavior.

The download endpoint streams files to authenticated users but does not log the download event. This makes it impossible to audit who downloaded which file and when, which is a data exfiltration detection gap.

The download endpoint does not implement rate limiting. An attacker could abuse this to perform a large number of download requests, potentially exhausting network bandwidth, CPU, or memory resources in the container, leading to denial of service.

**Perspective 1:** The download endpoint serves files from R2 storage with no rate limiting. An attacker can repeatedly request large files to consume bandwidth and egress costs. **Perspective 2:** The download endpoint has no rate limiting. An attacker could repeatedly request document downloads, each incurring egress bandwidth costs from R2/S3. While each download is cheap, unlimited downloads could lead to significant egress charges, especially for large documents.

The /download/:token endpoint has no rate limiting. An attacker could brute-force download tokens or perform a denial-of-service attack by requesting many downloads simultaneously.

The download endpoint does not log any audit events for successful or failed document downloads. There is no record of who downloaded which document, when, or from what IP address. This makes it impossible to detect unauthorized access or data exfiltration.

The download endpoint reads the entire file into memory via downloadFile(info.path) before sending it. For large files (e.g., 100 MB PDFs), this allocates a large buffer per request. Multiple concurrent downloads can exhaust server memory. There is no rate limiting on the download endpoint.

**Perspective 1:** The download endpoint verifies HMAC-signed tokens to authorize file downloads, which is good. However, the `info.path` from the decoded token is used directly to download files from storage. If the signing secret is compromised or if there's a vulnerability in the token verification, an attacker could craft tokens with path traversal sequences (e.g., '../') to access arbitrary files. **Perspective 2:** The download endpoint validates HMAC tokens but does not sanitize the storage path parameter. If the HMAC validation is bypassed or a token is leaked, an attacker could use path traversal to access arbitrary files. **Perspective 3:** The download endpoint validates HMAC tokens but does not sanitize the file path or key parameter. If the HMAC validation can be bypassed or if the token generation is weak, an attacker could use path traversal techniques (e.g., '../') to access files outside the intended directory.

The code uses Supabase's `eq()` method with a user-controlled value (`info.path`). While Supabase's `eq()` is parameterized and safe from SQL injection, the `info.path` value comes from a verified HMAC token, reducing risk. However, the token verification uses `timingSafeEqStr` which is a custom implementation and could have flaws.

The code uses Supabase's `eq()` method with `version.document_id` which comes from the database, not user input. This is safe from SQL injection. However, the `info.path` used in the previous query comes from a decoded token and could be manipulated if the HMAC is broken.

When accessing a project chat, if the project is not found or the user doesn't have access, a 404 is returned. This allows attackers to distinguish between 'project does not exist' and 'project exists but you don't have access'.

When a chat_id is provided but does not match the project, the endpoint silently creates a new chat. This could lead to confusion or potential abuse where a user might inadvertently create duplicate chats. More importantly, it does not verify that the provided chat_id belongs to the user or that the user has access to it.

When checking if a chat belongs to a project, if the chat is not found or doesn't belong to the project, chatId is set to null and a new chat is created. This behavior differs from returning a 404, potentially leaking information about chat existence.

The project chat streaming endpoint logs the full error object to the console on stream errors. This could expose internal implementation details.

**Perspective 1:** The POST /projects/:projectId/documents endpoint accepts file uploads without rate limiting. An attacker could upload many large files to exhaust disk space or memory in the container, leading to denial of service. The upload handler also performs CPU-intensive operations like PDF page counting and DOCX conversion. **Perspective 2:** The document upload handler performs CPU and memory-intensive operations including PDF parsing (pdfjs-dist), DOCX conversion (libreoffice), and structure tree extraction. These operations run in the main request handler without timeouts or resource limits, which could lead to container resource exhaustion from large or malicious documents.

The code imports 'mammoth' and 'pdfjs-dist' without any integrity check. These libraries are used for document processing and could be exploited if compromised. The package-lock.json provides some protection, but additional verification is recommended.

Same pattern as tabular.ts — uses `db.auth.admin.listUsers({ perPage: 1000 })` for access control resolution. Will silently fail for deployments with more than 1000 users.

Project creation, update, deletion, document upload, folder operations, and sharing changes are not logged to an audit trail. There is no record of who performed what action on which project and when. This makes it impossible to investigate unauthorized access or data exfiltration.

The `/projects/:projectId/people` endpoint uses `db.auth.admin.listUsers()` to list all users, which is an admin-level operation. This could expose user enumeration and is a performance concern.

The GET /projects/:projectId endpoint checks access by comparing the user's email against the shared_with array. This is case-insensitive but doesn't handle email aliases (e.g., user+tag@example.com) or domain changes. If a user changes their email, they lose access to projects shared with their old email.

The POST /projects/:projectId/documents/:documentId endpoint allows copying documents from other projects into the current project. While it checks that the document belongs to the user (eq('user_id', userId)), it does not verify that the source document's project is accessible to the user. An attacker could copy documents from projects they don't have access to, as long as they created those documents.

The PATCH /projects/:projectId endpoint only allows updates if the requesting user is the owner (user_id match). However, the shared_with field can be updated by the owner to add/remove members. If an attacker gains access to an owner's session, they can modify project sharing settings.

DOCX to PDF conversion errors are logged via console.error including the filename. This could leak information about which documents are being processed and their conversion status.

The GET /projects/:projectId/documents endpoint returns all documents in a project without pagination. An attacker with access to a project can enumerate all documents, including their metadata (filenames, types, sizes). Combined with the document download endpoints, this enables bulk exfiltration of all project documents.

The handleDocumentUpload function uses the original filename from the upload (file.originalname) to construct the storage key via storageKey(userId, docId, filename). If the filename contains path traversal characters (e.g., '../'), it could potentially write files outside the intended storage directory, leading to arbitrary file write or overwrite of existing files.

The tabular review endpoints that call LLM APIs (generate, regenerate-cell, chat) have no rate limiting. An attacker could trigger many expensive LLM API calls, causing financial cost to the application owner and potential resource exhaustion in the container. These endpoints also perform CPU-intensive document processing.

The code imports '@anthropic-ai/sdk' and '@google/genai' without any integrity check. These SDKs are used for AI model interactions and could be exploited if compromised. The package-lock.json provides some protection, but additional verification is recommended.

**Perspective 1:** The comment on line 1 states 'We still enforce access via listAccessibleProjectIds so a stranger can't request an arbitrary project_id.' However, when `projectIdFilter` is provided but not in `projectIds`, the code returns an empty array `[]` instead of a 403/404 error. This silently hides the access violation rather than enforcing it, potentially masking unauthorized access attempts. **Perspective 2:** The code catches errors from `sharedErr` and `sharedDirectErr` with comments saying 'Don't fail the whole list when an auxiliary share query errors' and 'Log and continue so the user still sees their own reviews.' This means share-based access control can silently fail, potentially exposing reviews that should be restricted or hiding reviews that should be visible. **Perspective 3:** The code uses `db.auth.admin.listUsers({ perPage: 1000 })` to enumerate all users for access control resolution. This assumes the user base is under 1000 and will silently truncate results beyond that, potentially granting or denying access incorrectly for users beyond the first 1000. **Perspective 4:** The `parseCellContent` function has a try/catch that returns null for any parsing error. This means malformed cell content is silently treated as empty, potentially hiding data corruption or injection attempts. The function is used throughout the tabular review system. **Perspective 5:** The SSE stream error handlers use empty catch blocks `catch { /* ignore */ }` that silently swallow all errors. This means stream corruption or partial failures are invisible to monitoring and debugging. **Perspective 6:** The chat title generation is wrapped in a try/catch that silently continues on failure. While this is acceptable for a non-critical feature, the comment says 'best-effort — title generation should never break the chat' which is accurate but the silent failure could mask underlying issues. **Perspective 7:** Document text extraction errors are caught and logged, but the code continues with an empty markdown string. This means the LLM will process documents with no content, potentially generating incorrect results. The error is logged but not surfaced to the user. **Perspective 8:** The `/prompt` endpoint catches all errors from LLM response parsing and returns a 502 error. While this is proper error handling, the catch block is empty (`catch { ... }`) which means the specific error is lost. This makes debugging LLM integration issues difficult.

Tabular review creation, update, deletion, cell clearing, cell regeneration, and chat operations are not logged to an audit trail. There is no record of who performed what action on which review and when. This makes it impossible to investigate unauthorized access or data manipulation.

The CORS configuration allows any origin to access the API. This can expose sensitive endpoints to unauthorized third-party websites.

Database error messages from tabular_reviews queries are logged via console.warn. These error messages may contain database schema details, query parameters, or other internal information that could aid an attacker in understanding the database structure.

Database error messages from tabular_reviews shared-by-email query are logged via console.warn. These error messages may contain database schema details, query parameters, or other internal information that could aid an attacker in understanding the database structure.

The POST /tabular-review endpoint accepts `document_ids`, `columns_config`, `workflow_id`, and `project_id` without schema validation. Malformed or excessively large inputs could cause resource exhaustion or database errors.

The PATCH /tabular-review/:reviewId endpoint uses ensureReviewAccess which allows both owners and shared members to update the review. However, shared_with changes are restricted to owners. The issue is that shared members can modify columns_config and document_ids, which could be used to manipulate the review structure.

The DELETE /tabular-review/:reviewId endpoint only checks that the review's user_id matches the requesting user. It doesn't use ensureReviewAccess, which means shared members cannot delete the review (correct), but it also doesn't check if the review exists before attempting deletion.

The `/tabular-review/:reviewId/people` endpoint uses `db.auth.admin.listUsers()` to list all users, which is an admin-level operation. This could be a performance issue and exposes user enumeration if not properly scoped.

Document extraction errors are logged via console.error including the document ID. While the document ID alone may not be sensitive, in combination with other logs it could be used to correlate extraction failures with specific documents.

The DELETE /tabular-review/:reviewId/chats/:chatId endpoint only checks that the chat belongs to the requesting user (user_id match). However, the comment says 'Owner-only delete — sibling collaborators shouldn't be able to wipe each other's threads.' The implementation correctly restricts to chat owner, but the review access check is missing - any authenticated user who can guess a chat ID could attempt deletion even without review access.

The GET /tabular-review/:reviewId/chats/:chatId/messages endpoint verifies review access and then checks that the chat exists and belongs to the review. However, the error message for 'Chat not found' is the same regardless of whether the chat doesn't exist or doesn't belong to the review, which is good for security. But the chat access check only verifies review_id match, not user ownership - any review member can read any chat in the review.

Document extraction errors during batch generation are logged via console.error including the document ID. This could leak information about which documents are being processed and their extraction status.

LLM query errors during batch generation are logged via console.error including the document ID. This could leak information about which documents are being processed and their processing status.

Stream errors during tabular generation are logged via console.error with the full error message. These error messages may contain sensitive information about the system state or data being processed.

The tabular review endpoints perform different database queries depending on whether the user has access (checking project access, shared_with, etc.) vs. not having access. The timing difference between these code paths could allow an attacker to enumerate valid review IDs and determine which users have access to which reviews.

The `/tabular-review/:reviewId/generate` endpoint uses Server-Sent Events (SSE) without connection rate limiting or timeout enforcement. An attacker could open many connections to exhaust server resources.

Chat errors during tabular review chat are logged via console.error with the full error message. These error messages may contain sensitive information about the system state or data being processed.

The DELETE /tabular-review/:reviewId/chats/:chatId endpoint only verifies chat ownership (user_id matches), but does not verify that the chat belongs to the specified review. An attacker could delete chats from other reviews by guessing or enumerating chat IDs. While the review access check is performed separately, the chat deletion bypasses review-level access control.

The GET /tabular-review/:reviewId/people endpoint returns the owner's email and display name, plus all shared members' emails and display names. This information is available to anyone with access to the review. An attacker with access to a single review can enumerate all users who have access to that review, enabling targeted social engineering attacks.

**Perspective 1:** Same pattern as tabular.ts and projects.ts — uses `db.auth.admin.listUsers({ perPage: 1000 })` for resolving sharer emails. Will silently fail for deployments with more than 1000 users. **Perspective 2:** The `getAdminClient` function uses empty string fallbacks for `NEXT_PUBLIC_SUPABASE_URL` and `SUPABASE_SECRET_KEY`. If these env vars are missing, the admin client will be created with empty credentials, and subsequent calls will fail with unclear errors.

Workflow creation, update, deletion, and sharing operations are not logged to an audit trail. There is no record of who created, modified, deleted, or shared workflows and when. This makes it impossible to investigate unauthorized changes to workflows.

The workflow shares endpoint uses `admin.auth.admin.listUsers()` to list all users for resolving sharer information. This is an admin-level operation that could be a performance and security concern.

The GET /workflows endpoint fetches all workflow shares for the current user's email, then uses the admin client to look up sharer emails and display names. This leaks user email information through the shared_by_name field in the response.

The GET /workflows endpoint uses an admin Supabase client (getAdminClient()) to list all auth users when resolving sharer information. This exposes the entire user database (emails, user IDs) to any authenticated user who has workflows shared with them. An attacker could enumerate all users in the system by creating multiple workflows and sharing them.

The DELETE /workflows/:workflowId endpoint only allows deletion if the workflow's user_id matches the requesting user. This is correct for ownership, but the error message 'Workflow not found' for non-owners could leak information about workflow existence.

The DELETE /workflows/:workflowId/shares/:shareId endpoint verifies ownership by checking the workflows table, but then uses the regular db client (not admin) to delete from workflow_shares. While ownership is checked, the endpoint doesn't verify the share belongs to the workflow, potentially allowing an attacker to delete shares from other workflows if they can guess share IDs.

The account settings page only has two tabs: 'General' and 'Models & API Keys'. There is no password change tab or functionality. Users cannot change their passwords, which means if a password is compromised, there is no self-service way to rotate credentials. This also means there is no mechanism to require current password verification before changing credentials.

The API keys page allows users to input and save Claude and Gemini API keys. These keys are stored in the user profile (likely in Supabase) and retrieved on the client side. The keys are exposed to client-side JavaScript and could be leaked through XSS, browser extensions, or network monitoring.

**Perspective 1:** API key updates (save/change) lack audit logging. There is no record of when a user changed their API keys, which provider was affected, or the result. This is a security gap for credential management. **Perspective 2:** Model preference changes (e.g., tabular review model selection) lack audit logging. There is no record of when a user changed their model preferences.

The API key input fields have a show/hide toggle (Eye/EyeOff icons). While this is standard UX, the keys are stored in plaintext in the DOM and could be accessed via browser dev tools or extensions.

**Perspective 1:** The account settings page does not include any option to change the user's password. Users cannot update their credentials if they suspect their password has been compromised. This is a significant gap in credential management. **Perspective 2:** The account page has no password-related settings or strength indicators. If password functionality is handled by Supabase Auth, there is no client-side guidance on password requirements (minimum length, complexity). Users may choose weak passwords without understanding the requirements.

Changes to display name, organisation, and account deletion are not logged to an audit trail on the frontend. While the backend handles the actual mutations, there is no client-side record of these actions. Account deletion in particular should have a clear audit trail.

The handleDeleteAccount function catches errors and displays 'Failed to delete account. Please try again.' This is acceptable, but the catch block doesn't log the actual error, making debugging difficult and potentially masking security-relevant failures.

The page component uses use(params) to extract reviewId and id from the URL. If these parameters are not validated, an attacker could use path traversal sequences to access unauthorized resources. The parameters are passed directly to TRView component.

The TabularReviewsPage component has a bulk delete action that filters reviews by ownership client-side before sending delete requests. The filtering logic has a fallback that could allow non-owners to attempt deletion. The server-side enforcement is unclear.

The workflow detail page renders the workflow title via `RenameableTitle` component. The title is user-provided and stored in the database. If the title contains HTML or JavaScript, it could be rendered unsanitized depending on how `RenameableTitle` handles the value. The title is also used in the breadcrumb and other UI elements without sanitization.

The AddDocButton component allows uploading multiple files via a file input, but there's no server-side validation of upload limits (file count, total size, or storage quotas). The component only has client-side accept attribute for file types. An attacker could upload an unlimited number of documents or excessively large files, potentially exhausting storage resources or incurring costs.

**Perspective 1:** The NEXT_PUBLIC_API_BASE_URL defaults to 'http://localhost:3001' which uses unencrypted HTTP. In production, this should always be HTTPS to prevent credential interception. **Perspective 2:** The download mechanism fetches files with Authorization header, but the download URL is constructed from user-controlled data. If the URL is logged or leaked, the token could be exposed.

**Perspective 1:** The frontend relies on npm packages (react-markdown, remark-math, rehype-katex, etc.) without any integrity verification mechanism such as lockfile v2 integrity hashes or npm audit enforcement in CI. Compromised packages could inject malicious code into the client-side application. **Perspective 2:** The project does not implement any artifact signing for built frontend assets. Without signing, there is no way to verify that deployed JavaScript bundles originated from the trusted build pipeline and were not tampered with during storage or transit. **Perspective 3:** The component imports 'katex/dist/katex.min.css' from an npm package. While npm provides some integrity guarantees via lockfile, there is no additional verification that the CSS hasn't been tampered with. A compromised KaTeX package could inject malicious styles or use CSS exfiltration techniques.

**Perspective 1:** The DocDownloadBlock component constructs download URLs using the download_url property from the event data. If an attacker can control the download_url value, they could potentially redirect downloads to arbitrary URLs or trigger SSRF. **Perspective 2:** The NEXT_PUBLIC_API_BASE_URL environment variable is used to construct API endpoints. If an attacker can control this environment variable, they could redirect all API calls to a malicious server. There is no validation that the URL points to the expected backend.

The bulk accept/reject and individual edit resolution actions do not log user identity, action type, timestamp, or document/version IDs to an audit trail. SOC 2 CC7.2 requires monitoring and logging of security events. HIPAA §164.312(b) requires audit controls that record and examine activity in information systems containing PHI.

The SSE data is parsed with JSON.parse and the resulting object properties are used directly without sanitization. If an attacker can control the SSE stream, they could inject __proto__ or constructor properties to pollute the Object prototype.

**Perspective 1:** The API base URL falls back to 'http://localhost:3001' when NEXT_PUBLIC_API_BASE_URL is not set. In production, this could cause the application to attempt connections to localhost, potentially leaking data or causing unexpected behavior. More critically, the use of HTTP (not HTTPS) for the fallback means traffic could be intercepted. **Perspective 2:** The API base URL falls back to http://localhost:3001 when NEXT_PUBLIC_API_BASE_URL is not set. This insecure HTTP fallback is used in production builds for assistant message rendering, potentially leaking data over unencrypted connections. **Perspective 3:** The API base URL falls back to 'http://localhost:3001' when NEXT_PUBLIC_API_BASE_URL is not set. This can cause the frontend to connect to a local development server in production.

The `API_BASE` constant falls back to 'http://localhost:3001' when `NEXT_PUBLIC_API_BASE_URL` is not set. This insecure HTTP URL is used silently in production if the env var is missing. The comment says 'Only backend-relative URLs are accepted' but the fallback is an absolute HTTP URL.

The comment claims 'Only backend-relative URLs are accepted' and 'any absolute URL from tool output is refused', but the check is simply `download_url.startsWith('/')`. This can be bypassed with URLs like '//evil.com/path' (protocol-relative URL) or '/../../etc/passwd' (path traversal). The check does not validate that the URL is actually a safe backend path.

Opening, closing, and switching tabs in the assistant side panel lacks audit logging. While less critical, tab operations reveal user behavior and document access patterns.

The AssistantSidePanel displays document tabs without re-verifying user authorization when switching between documents. SOC 2 requires continuous access verification.

The `AssistantWorkflowModal` component renders user-controlled workflow prompt content using `ReactMarkdown`. If the prompt contains malicious markdown or HTML, it could lead to XSS or other injection attacks.

The ChatInput component receives apiKeys (claudeApiKey, geminiApiKey) from the UserProfile context and passes them to isModelAvailable() on the client side. This means API keys are accessible in client-side JavaScript, potentially exposing them to XSS attacks or browser extension access.

The file upload in `ProjectExplorer.tsx` accepts `.pdf`, `.docx`, and `.doc` files via the `accept` attribute on the file input. This is a client-side restriction and can be easily bypassed by modifying the request or using the browser's developer tools. An attacker could upload arbitrary file types, potentially leading to storage abuse or other issues.

ChatView processes message events and annotations which could contain prototype pollution payloads. The code accesses properties like (msg as any).files, (msg as any).workflow, (msg as any).error without validation. If an attacker can inject __proto__ or constructor properties into the message objects, it could lead to prototype pollution.

The `ChatView` component renders LLM-generated content through `UserMessage` and `AssistantMessage` components. While these components likely use React's built-in XSS protection, the content is not sanitized for potentially dangerous markdown or HTML that could be rendered by the markdown renderer.

**Perspective 1:** The `handle` function in `EditCard` sends a POST request to accept or reject an edit. There is no visible server-side validation that the user owns the document or has permission to modify it. A malicious user could potentially accept/reject edits on documents they don't own by manipulating the request. **Perspective 2:** The `applyOptimisticResolution` function applies a visual change to the DOM immediately when the user clicks Accept/Reject. If the server request fails, the `revert` function is called to undo the change. However, if the revert function itself throws an error (which is caught but logged), the DOM could be left in an inconsistent state. **Perspective 3:** The `handle` function in `EditCard` sends a fetch request to the backend. The `Authorization` header is set to `Bearer ${token}` where `token` is the Supabase session access token. While this is standard practice, the token is exposed in the client-side code and could be intercepted if HTTPS is not enforced. **Perspective 4:** The `handle` function sets `busy` to true and calls `onResolveStart` before making the API request. However, there is no locking mechanism to prevent multiple concurrent requests for the same edit. If the user clicks Accept/Reject multiple times rapidly, multiple requests could be sent.

The EditCard component logs detailed debug information to the console, including DOM element counts, data-w-id values, and text matching results. This exposes internal implementation details about how tracked changes are managed.

The applyOptimisticResolution function logs document_id, ins_w_id, del_w_id, and truncated text content to the console. This exposes internal document structure and edit tracking identifiers.

When the optimistic DOM mutation fails, the error is logged to the console via console.error. This exposes internal implementation details.

**Perspective 1:** The API base URL falls back to 'http://localhost:3001' when NEXT_PUBLIC_API_BASE_URL is not set. In development, this transmits session tokens over unencrypted HTTP, making them susceptible to interception. **Perspective 2:** The error handler logs the full error object which may contain the request URL including the token query parameter. This could expose tokens in browser developer tools or logging systems.

The code calls supabase.auth.getSession() to retrieve the user's access token and then uses it in a fetch call. The token is exposed in client-side memory and could be accessed by browser extensions, injected scripts, or XSS attacks.

The API base URL defaults to 'http://localhost:3001' if NEXT_PUBLIC_API_BASE_URL is not set. In production, this could cause credentials to be sent over unencrypted HTTP if the environment variable is misconfigured.

The EditCard component makes a fetch request to the backend API with an Authorization header containing the user's access token. The API base URL is constructed from an environment variable NEXT_PUBLIC_API_BASE_URL, which is exposed to the client. While this is standard practice for client-side API calls, the token is exposed to any JavaScript running in the browser.

When an edit accept/reject fails, the error is logged to the console via console.error. This exposes the failure to any user with developer tools open.

When reverting an optimistic DOM mutation fails, the error is logged to the console via console.error. This exposes internal implementation details.

The InitialView component allows users to submit messages without any apparent rate limiting. An attacker could rapidly submit messages to exhaust their credit allowance or overwhelm the backend, potentially causing denial of service or excessive API costs.

The ModelToggle component receives apiKeys (claudeApiKey, geminiApiKey) as props and passes them to isModelAvailable() to determine which models to enable/disable. This exposes the user's API keys to client-side JavaScript code.

**Perspective 1:** The `ModelToggle` component allows the user to select a model from a dropdown list. The selected model ID is sent to the backend as part of the chat request. While the frontend has a hardcoded list of allowed models, the backend does not appear to validate that the received model ID is in the allowlist. An attacker could craft a request with an arbitrary model ID, potentially loading an unverified or malicious model. **Perspective 2:** The model selection UI allows users to pick any model from a list, but there is no server-side validation to ensure the selected model is allowed for that user or use case. A compromised client could send an arbitrary model ID. **Perspective 3:** The model selection UI allows users to pick from a set of model IDs. If the selected model ID is passed to the backend without validation against an allowlist, an attacker could potentially specify a malicious model endpoint or an unintended model provider. The backend should validate the model ID against a server-side allowlist before using it. **Perspective 4:** The model selection UI allows users to select from a list of models. If the model selection is sent to the backend as a user-controlled parameter without server-side validation, an attacker could modify the request to use a different model than intended, potentially bypassing cost controls or using unapproved models.

The SelectAssistantProjectModal allows users to select a project and create a chat within it. There's no visible server-side validation that the user has permission to access the selected project before the chat is created. A user could potentially create chats in projects they don't have access to by manipulating the project ID.

UserMessage component renders user-controlled content via whitespace-pre-wrap. While this is plain text rendering, if the content is later processed by a template engine or markdown renderer elsewhere in the component tree, it could lead to SSTI. The content originates from user input and could contain template syntax.

The `UserMessage` component renders user-provided filenames directly in the DOM. While filenames are typically safe, an attacker could upload a file with a malicious filename containing HTML/script content that gets rendered in the chat message.

Bulk chat deletion lacks audit logging. There is no record of when a user deleted multiple chats, how many, or the result.

The DeleteChatsModal allows bulk deletion of chat history without logging the action. SOC 2 requires logging of data deletion events.

The `SimpleLinkDialog` generates a share URL for a chat. There is no visible mechanism to revoke access to a shared link once it's been generated. If a share link is leaked, anyone with the link can access the chat indefinitely.

SimpleLinkDialog renders shareUrl directly in the UI. If shareUrl contains malicious JavaScript (e.g., javascript: URLs), clicking the copy button or the link could lead to XSS. The URL is displayed as text but could be used in anchor tags or other contexts.

**Perspective 1:** The breadcrumb array is rendered directly into the DOM. If any breadcrumb segment contains user-controlled data (like project names), it could lead to XSS. The breadcrumb segments should be properly escaped. **Perspective 2:** The `NewProjectModal` renders breadcrumb items as text content. While React escapes text by default, the breadcrumb items are hardcoded strings in this case, so the risk is minimal.

The NewProjectModal component accepts project name and CM number from the user without any sanitization. These values are later displayed in the UI and could contain malicious content if not properly encoded.

Project creation events, including shared member assignments, are not audited. There is no record of who created which project, when, or with what initial members and documents.

ProjectExplorer renders folder names and document filenames directly in React components. While React escapes text content, if these values are used in dangerouslySetInnerHTML or passed to markdown renderers, they could lead to XSS. The names come from user input and could contain malicious characters.

ProjectExplorer uses custom MIME types (application/mike-doc, application/mike-folder) for drag-and-drop operations. If an attacker can craft malicious drag events with these MIME types containing manipulated data, they could trigger unauthorized document moves or folder operations.

The ProjectPage component allows creating, renaming, and deleting folders, but there's no visible server-side validation that the user has permission to perform these operations on the project. A user could potentially manipulate folders in projects they don't own by calling the API directly.

The ProjectsOverview component has a bulk delete action that filters projects by ownership client-side before sending delete requests. However, the filtering logic has a fallback that could allow non-owners to attempt deletion. The server-side enforcement is unclear.

**Perspective 1:** The breadcrumb array is rendered directly into the DOM. If any breadcrumb segment contains user-controlled data (like document names), it could lead to XSS. The breadcrumb segments should be properly escaped. **Perspective 2:** The `AddDocumentsModal` renders breadcrumb items as text content. While React escapes text by default, the breadcrumb items are user-controlled strings that could contain malicious content if not properly validated.

The AddDocumentsModal allows users to select documents from any project or standalone documents and add them to a tabular review. There is no server-side verification that the user has access to the documents they are adding. This could allow privilege escalation where a user adds documents they should not have access to. Violates SOC 2 CC6.1.

Document deletion operations are not audited. There is no record of who deleted which document or when, making it impossible to investigate data loss incidents.

The AddProjectDocsModal renders document filenames directly in the UI without sanitization. Document filenames are user-provided and could contain HTML or script content that would be rendered by React.

The `AddProjectDocsModal` renders `breadcrumb` array items as text content. While React escapes text content by default, the breadcrumb items are user-controlled strings that could contain malicious content if not properly validated.

Document selection from a project for adding to a review or chat lacks audit logging. There is no record of which documents were selected by whom.

The AddProjectDocsModal fetches project documents without verifying the user's authorization to view each document. While project-level access is checked, document-level access is not independently verified. SOC 2 requires granular access controls.

The code renders document filenames directly in the UI without sanitization. While React's JSX escapes HTML, if the filename contains special characters or is used in URL construction, it could lead to DOM-based XSS. The filename is used in download URLs and displayed in the UI.

**Perspective 1:** The DocPanel component retrieves the Supabase auth token from the client-side session (supabase.auth.getSession()) to make authenticated API calls. This token is stored in localStorage by default and is accessible to any JavaScript on the page. **Perspective 2:** The download function in DocPanel uses `process.env.NEXT_PUBLIC_API_BASE_URL ?? 'http://localhost:3001'` with an HTTP fallback. If the environment variable is not set, API keys and auth tokens would be transmitted in plaintext over HTTP.

The DownloadButton in DocPanel fetches document bytes via /single-documents/:documentId/docx and creates a Blob in memory. An attacker could trigger downloads of very large documents, causing client-side memory exhaustion. The response is not streamed to disk.

**Perspective 1:** The DocPanel component uses DocxView which depends on the docx-preview library. There is no integrity verification (SRI hash) for this library when loaded. A compromised docx-preview could execute arbitrary JavaScript in the context of the application, potentially exfiltrating documents or user data. **Perspective 2:** The DocPanel component uses DocView which depends on PDF.js. There is no integrity verification for this library. A compromised PDF.js could execute arbitrary JavaScript, potentially exfiltrating document contents or user session tokens.

The `DocPanel` component renders `filename` directly in the UI. While this is rendered as text content in JSX (which React escapes), the filename is also used in download URLs and could contain path traversal characters if not properly validated.

**Perspective 1:** The document download button in the DocPanel component does not log download events. There is no record of which user downloaded which document version. **Perspective 2:** The Accept/Reject buttons in the DocPanel component do not log edit resolution events. While the backend handles the resolution, there is no client-side audit trail of user actions.

**Perspective 1:** The API base URL falls back to http://localhost:3001 when NEXT_PUBLIC_API_BASE_URL is not set. This insecure HTTP fallback is used in production builds for document download functionality, potentially leaking data over unencrypted connections. **Perspective 2:** The API base URL falls back to 'http://localhost:3001' when NEXT_PUBLIC_API_BASE_URL is not set. This can cause the frontend to connect to a local development server in production.

The getPdfJs function loads PDF.js dynamically. If the PDF.js library is compromised or loaded from an untrusted source, it could execute arbitrary code in the browser context. There is no Subresource Integrity (SRI) check on the loaded library.

**Perspective 1:** The DocView component renders PDFs with no page count limit. An attacker can upload a PDF with thousands of pages, consuming CPU and memory for rendering. Each page render is a billable operation. **Perspective 2:** The DocView component renders PDF documents without any page count limits. An attacker could upload a PDF with thousands of pages, each requiring rendering resources. On serverless infrastructure, this could lead to high compute costs proportional to the number of pages rendered.

The DocView component renders all pages of a PDF document into the DOM. A maliciously crafted PDF with thousands of pages could cause the browser to allocate excessive memory and CPU time, potentially freezing the tab. There is no limit on the number of pages rendered.

The quote text from citations is used directly in DOM text search operations without sanitization. While this is primarily a client-side operation, quotes containing special characters could cause unexpected behavior in the text layer search.

The DocViewModal renders document filenames without sanitization, which could lead to DOM-based XSS if the filename contains malicious content.

The `handleDownload` function creates a temporary anchor element with `a.href = url` where `url` comes from `getDocumentUrl(doc.id, versionId)`. If the backend returns a URL that redirects to an external site, or if the URL itself is attacker-controlled, this could be used as an open redirect. The `a.download` attribute is set, but the browser may still navigate to the URL if the download fails or if the URL points to a different origin.

**Perspective 1:** The DocumentCard component renders document filenames directly. If a filename contains HTML special characters, it could lead to XSS. While React escapes text content by default, the filename is used in a title attribute which should also be escaped. **Perspective 2:** The `DocumentCard` component renders document filenames directly. While React escapes text content by default, filenames could contain special characters that might be interpreted unsafely in other contexts.

The DocumentCard component displays the document filename without sanitization. If a filename contains malicious HTML or JavaScript, it could be executed when the component renders. The filename is used in the title attribute and as text content.

**Perspective 1:** console.log in DocxView logs documentId, versionId, refetchKey, and byte length. This could expose document metadata and processing status to browser extensions or logging infrastructure. **Perspective 2:** The tracked-change-ids fetch includes the user's bearer token in the Authorization header. If the backend logs request headers, the token could be exposed. Also, the fetch URL includes versionId as a query parameter, which could be logged. **Perspective 3:** console.warn in tagWIdsOnRenderedDom logs the HTTP status code when the tracked-change-ids fetch fails. While not directly sensitive, it indicates internal API structure.

The docx-preview library is loaded dynamically via dynamic import. If the library is compromised, it could execute arbitrary code during document rendering. There is no integrity verification of the loaded library.

**Perspective 1:** The DocxView component renders DOCX files with no limits on document complexity. An attacker can upload a DOCX with many pages or complex formatting, consuming CPU and memory for rendering. **Perspective 2:** The DocxView component renders DOCX documents without limits on document complexity (number of paragraphs, images, tracked changes). An attacker could upload a DOCX with thousands of tracked changes or embedded images, each requiring processing resources. On serverless infrastructure, this could lead to high compute costs.

The DocxView component renders the entire DOCX document into the DOM using docx-preview. A malicious DOCX file with thousands of pages, complex tables, or embedded images could cause the browser to allocate excessive memory and CPU, potentially freezing the tab. There is no limit on document size or complexity.

The DocxView component fetches tracked-change-ids from the backend. The backend endpoint does not appear to verify that the requesting user has access to the document before returning the list of tracked change IDs. This could allow unauthorized users to enumerate tracked changes in documents they should not access. Violates SOC 2 CC6.1 (logical access controls).

The API response is parsed with JSON.parse and the resulting object properties are used directly without sanitization. If an attacker can control the API response, they could inject __proto__ or constructor properties to pollute the Object prototype.

**Perspective 1:** Multiple components use 'http://localhost:3001' as fallback for API calls. This HTTP connection could expose sensitive document data and authentication tokens to network interception. **Perspective 2:** The API base URL falls back to 'http://localhost:3001' when NEXT_PUBLIC_API_BASE_URL is not set. This can cause the frontend to connect to a local development server in production.

**Perspective 1:** The EMAIL_RE regex /^[^\s@]+@[^\s@]+\.[^\s@]+$/ is very permissive and allows email addresses with special characters that could be used for injection attacks. It does not properly validate the domain part or limit the length of the email address. **Perspective 2:** The addEmail function trims and lowercases the email but does not sanitize it for special characters. While this is primarily used for sharing access, the email could contain characters that cause issues in downstream API calls or database queries.

The `EMAIL_RE` regex is used to validate email addresses. An attacker could potentially bypass this validation with a crafted email string that passes the regex but contains malicious content (e.g., SQL injection or XSS payloads) that is later used in API calls.

When users are added or removed from shared resources (projects, reviews), there is no audit logging of these permission changes. This makes it impossible to track who gained or lost access to sensitive documents and when.

**Perspective 1:** The email validation regex /^[^\s@]+@[^\s@]+\.[^\s@]+$/ is very permissive and would accept invalid email formats like 'a@b.c' or 'test@test..com'. This could allow invalid or malicious email addresses to be added. **Perspective 2:** The email input field has no maximum length constraint. An attacker could paste an extremely long string causing memory issues or UI overflow.

**Perspective 1:** The EMAIL_RE regex /^[^\s@]+@[^\s@]+\.[^\s@]+$/ is very permissive and allows many invalid email formats (e.g., 'a@b.c', 'test@test..com'). This could allow users to be granted access with invalid email addresses, potentially bypassing email-based access controls. **Perspective 2:** The email sharing feature accepts any valid email address without checking against a domain allowlist or blocklist. This could allow unauthorized external users to be granted access to sensitive documents.

The `validate` prop accepts an async function that checks if an email is valid. If this validation checks against a user database without tenant scoping, it could be used to enumerate whether an email exists in any tenant. The error message 'Could not verify email' could leak information about user registration status.

The `onDelete` handler in `FileDirectory` receives a set of document IDs from the client. There is no server-side validation that the user owns or has permission to delete these documents. A malicious user could potentially delete documents they don't own by manipulating the request.

FileDirectory renders document filenames directly in React components. While React escapes text content by default, if filenames are used in dangerouslySetInnerHTML or passed to markdown renderers, they could lead to XSS. Filenames from uploaded documents could contain malicious characters.

The OwnerOnlyModal component displays a warning when a non-owner attempts an owner-only action, but the actual enforcement appears to be client-side only. The component shows a message like 'Only the project owner can delete this document' but doesn't prevent the API call from being made. A user could bypass this modal by directly calling the API endpoints.

The `PeopleModal` accepts user input for email addresses and sends them directly to the backend via `onSharedWithChange` without any sanitization beyond a regex validation. The regex `EMAIL_RE` only validates the format but does not sanitize the input. If the backend does not properly sanitize the email before storing or using it in queries, this could lead to injection attacks.

Adding or removing members via the PeopleModal calls onSharedWithChange which patches the resource's shared_with list. There is no audit trail of who added/removed whom and when. This makes it impossible to investigate unauthorized sharing changes.

**Perspective 1:** The ReasoningBlock component renders user-controlled text via ReactMarkdown. While ReactMarkdown escapes raw HTML, the custom components could introduce XSS vectors. The reasoning text from the LLM could contain malicious markdown that exploits custom component rendering. **Perspective 2:** The `PreResponseWrapper` component renders `children` directly. When used in `TRChatPanel`, it wraps `ReasoningBlock` which uses `ReactMarkdown` to render user-controlled reasoning text. The reasoning text from the LLM could contain malicious markdown that ReactMarkdown renders as HTML. **Perspective 3:** The `PreResponseWrapper` component renders `children` directly. When used in `AssistantMessage`, it wraps `ReasoningBlock` which uses `ReactMarkdown` to render user-controlled reasoning text. The reasoning text from the LLM could contain malicious markdown that ReactMarkdown renders as HTML.

The `RenameableTitle` component renders user-provided titles directly in the DOM. While the title is user-controlled, it could contain HTML/script content if an attacker can influence the title value through other means (e.g., API manipulation).

Document actions like delete, hide, unhide, rename, and version management are not audited. There is no record of who performed these actions or when.

The `SidebarChatItem` renders `chat.title` directly as text content without any sanitization. The chat title is user-provided and could contain malicious content. While it's rendered as text content (not HTML), the lack of sanitization could still be problematic if the title is used in other contexts (e.g., as a tooltip or in API calls).

The UploadNewVersionModal accepts a user-provided display name for document versions without sanitization. This name is sent to the backend and later rendered in the UI. If not sanitized, it could contain XSS payloads.