**Perspective 1:** R2_ACCESS_KEY_ID and R2_SECRET_ACCESS_KEY are used in a client-side file (frontend/src/lib/storage.ts). These credentials are bundled with the frontend and exposed to all users, allowing anyone to read/write/delete objects in the R2 bucket. The backend has an identical copy (backend/src/lib/storage.ts) which is the correct location for server-side storage operations. **Perspective 2:** R2_SECRET_ACCESS_KEY is referenced in client-side code. This secret key grants full access to the R2 storage bucket. Any user who can view the frontend JavaScript can extract this key and access the storage bucket directly.

R2_ACCESS_KEY_ID is referenced in client-side code. While less sensitive than the secret key, it still provides information that aids in attacking the storage infrastructure.

R2_ENDPOINT_URL is referenced in client-side code, revealing the Cloudflare R2 endpoint URL. Combined with the exposed credentials, this gives attackers all information needed to access the storage bucket.

R2_BUCKET_NAME is referenced in client-side code with a default value of 'mike'. This exposes the storage bucket name to all users.

An S3Client is instantiated with R2 credentials in client-side code. This allows direct programmatic access to the R2 bucket from any user's browser.

The uploadFile function creates an S3Client with credentials and sends PutObjectCommand from client-side code. Any user can upload arbitrary files to the R2 bucket.

The downloadFile function creates an S3Client with credentials and sends GetObjectCommand from client-side code. Any user can download any file from the R2 bucket.

The deleteFile function creates an S3Client with credentials and sends DeleteObjectCommand from client-side code. Any user can delete any file from the R2 bucket.

The getSignedUrl function creates an S3Client with credentials and generates pre-signed URLs from client-side code. This exposes the signing process to users.

The `createServerSupabase()` function creates a Supabase client with the service role key (SUPABASE_SECRET_KEY). This key bypasses all Row-Level Security (RLS) policies. Any query made with this client can access all rows across all tenants. If this client is used in API routes without explicit tenant_id WHERE clauses, it will leak data across tenants.

When SUPABASE_SECRET_KEY or SUPABASE_URL is missing, the `getUserIdFromRequest` function falls back to returning the raw Bearer token as the user ID. This means any string passed as a token is accepted as a valid user ID, allowing complete impersonation of any user and access to any tenant's data. This is a severe security bypass.

The POST /projects/:projectId/chat endpoint triggers an LLM stream for every authenticated request. There is no rate limiting, no per-user spend cap, and no budget circuit breaker. An attacker with valid credentials can send unlimited requests, each incurring LLM API costs. The endpoint also accepts attached_documents which could increase context size and cost.

**Perspective 1:** The streamGemini function calls Google's Gemini API with no maxOutputTokens or cost limits. The maxIterations parameter defaults to 10 but does not limit per-iteration token count. An attacker can cause unbounded token generation by sending long prompts or many tool calls, each iteration incurring API costs. **Perspective 2:** The Gemini provider adapter does not enforce max_tokens on API calls. The generateContent and streamGenerateContent methods are called without a maxOutputTokens parameter, allowing the model to generate an unbounded number of tokens per request. This is a direct cost amplification vector.

**Perspective 1:** The `createServerSupabase` function uses `SUPABASE_SECRET_KEY` (the service role key) in a frontend file. The service role key bypasses all Row-Level Security (RLS) policies and has full access to the database. If this key is exposed to the client, an attacker can directly query or modify any data in the database. The file is in the frontend directory and imports from a client-side library. **Perspective 2:** The Supabase service role key (SUPABASE_SECRET_KEY) is used in a frontend file. This key bypasses Row-Level Security and grants full database access. Exposure allows an attacker to read, modify, or delete all data. **Perspective 3:** The Supabase service_role key is imported and used in frontend code (supabase-server.ts). The service_role key bypasses Row Level Security (RLS) and has full access to all data. Exposing this key in client-side code allows any user to extract it from the JavaScript bundle and gain unrestricted database access.

**Perspective 1:** In the `getUserIdFromRequest` function, if the Supabase URL or service key is not configured, the function falls back to accepting the raw token string as the user ID. This means in development or misconfigured environments, any string can be used as a user ID, completely bypassing authentication. An attacker could impersonate any user by sending their ID as the token. **Perspective 2:** When SUPABASE_SECRET_KEY is not set, the code falls back to using the raw token string as the user ID. This completely bypasses authentication and allows anyone to impersonate any user by providing an arbitrary token. **Perspective 3:** In development mode, the code accepts a raw token string as the user ID without any validation. This completely bypasses authentication and allows anyone to impersonate any user by providing an arbitrary user ID. If this code path is accidentally enabled in production, it's a complete authentication bypass.

The schema enables RLS on user_profiles but does not enable or define RLS policies on any other multi-tenant tables including projects, documents, document_versions, document_edits, chats, chat_messages, tabular_reviews, tabular_cells, workflows, or workflow_shares. Without RLS, any authenticated user can read or modify any tenant's data through the Supabase API.

**Perspective 1:** The completeGeminiText function calls Gemini's generateContent with no maxOutputTokens. This is used for column prompt generation and other tasks, allowing unbounded token consumption per call. **Perspective 2:** The completeGeminiText function calls the Gemini API without a maxOutputTokens parameter. This helper is used for one-shot completions (e.g., title generation) where the response should be short. Without a token limit, the model could generate a very long response, increasing costs.

The requireAuth middleware creates a Supabase admin client using the service role key to verify user tokens. This bypasses all RLS policies for subsequent database operations performed by the caller. Any downstream code that uses the admin client or inherits the service role context can access any tenant's data without restriction.

The POST /chat endpoint initiates an LLM streaming response. There is no rate limiting on this endpoint, allowing an attacker to make unlimited requests and incur significant costs or exhaust API quotas. This is a critical issue as it can lead to financial abuse.

The DELETE /user/account endpoint calls db.auth.admin.deleteUser(userId) using the service role key, but only verifies the user is authenticated via requireAuth. There is no verification that the authenticated user owns the account being deleted. An attacker who can manipulate the userId (e.g., via a compromised session or token injection) could delete arbitrary user accounts. This is a direct privilege escalation from authenticated user to admin-level account deletion.

**Perspective 1:** The useAssistantChat hook streams LLM responses with no max_tokens, no per-user spend cap, and no circuit breaker. An attacker can send arbitrarily long prompts or many requests, causing unbounded LLM API costs. The hook calls streamChat/streamProjectChat which proxy to Gemini/Claude APIs with no token limit enforcement. **Perspective 2:** The useAssistantChat hook calls the chat API without any max_tokens parameter or budget controls. The LLM can generate an unbounded number of tokens per request. Combined with the ability to send unlimited messages, this creates a significant cost exposure.

**Perspective 1:** The code uses NEXT_PUBLIC_SUPABASE_PUBLISHABLE_DEFAULT_KEY (the anon/public key) to call supabase.auth.getUser(). This key is designed for client-side use and has no authority to validate tokens. The service role key should be used for server-side token validation. **Perspective 2:** The SUPABASE_SECRET_KEY (service role key) is imported in a file that may be bundled client-side. This key bypasses all Row Level Security and gives full database access. If an attacker can access this key, they can read, modify, or delete any data in the database.

The frontend/src/lib/storage.ts file contains S3 client initialization with credentials from environment variables. If this file is imported in client-side code, the R2_ENDPOINT_URL, R2_ACCESS_KEY_ID, and R2_SECRET_ACCESS_KEY environment variables could be exposed to the browser, allowing an attacker to directly access the R2 storage bucket.

The function createServerSupabase() uses SUPABASE_SECRET_KEY (the service role key) to create a Supabase client. This file is in the frontend/src/lib directory and is imported by client-side code. The service role key bypasses Row-Level Security (RLS) and grants full database access. If this key is bundled into client-side JavaScript, any user can extract it and gain unrestricted access to the database.

If SUPABASE_SECRET_KEY is not set, the function falls back to an empty string, which will cause the Supabase client to fail silently or behave unexpectedly. More importantly, the service role key should never be used in client-side code.

The SUPABASE_SECRET_KEY (service role key) is imported in a file that may be bundled client-side. This key bypasses all Row Level Security and gives full database access. If an attacker can access this key, they can read, modify, or delete any data in the database.

When SUPABASE_URL or SUPABASE_SECRET_KEY are not set, getUserIdFromRequest returns the raw Bearer token as the user ID. This means any string passed as the Authorization header is accepted as a valid user identity, allowing complete authentication bypass in development/staging environments that may be exposed.

**Perspective 1:** The handleGenerate function calls streamTabularGeneration which triggers LLM calls for every cell in the review. There is no limit on the number of columns or documents, no per-user spend cap, and no rate limiting. An attacker can create a review with many columns/documents and repeatedly click 'Run' to generate unlimited LLM API costs. **Perspective 2:** The handleRegenerateCell function calls regenerateTabularCell which triggers an LLM API call. There is no rate limiting or cost control on this action. An attacker can repeatedly regenerate cells to incur unlimited API costs. **Perspective 3:** The TabularReviewView component triggers LLM API calls for each cell in a tabular review. There is no limit on the number of columns, rows, or documents that can be processed. An attacker could create a review with hundreds of columns and thousands of documents, each triggering an LLM API call. The cost scales linearly with the number of cells.

**Perspective 1:** AssistantMessage renders streaming LLM responses with no max_tokens or cost limits. The component processes content_delta events indefinitely, allowing an attacker to generate arbitrarily long responses and incur unlimited LLM API costs. **Perspective 2:** The AssistantMessage component renders streaming LLM responses with no limits on token count. The streaming response is rendered as it arrives, and there is no mechanism to stop the stream if it exceeds a cost threshold. An attacker could craft prompts that cause the LLM to stream an extremely long response.

**Perspective 1:** The POST /chat endpoint triggers an LLM stream (runLLMStream) for every request. There is no rate limiting, no per-user spend cap, and no budget circuit breaker. An attacker can send unlimited requests, each incurring LLM API costs proportional to the response length. With no max_tokens enforcement on the streaming response, a single request could generate thousands of tokens, and unlimited requests could run up a massive bill. **Perspective 2:** The runLLMStream function is called without any max_tokens parameter visible in the route handler. The LLM can generate an unbounded number of tokens per request, each costing money. An attacker could craft prompts that cause the LLM to produce extremely long responses, amplifying the cost per request. **Perspective 3:** The chat endpoint calls runLLMStream which uses getUserApiKeys to get the user's API keys. There is no mechanism to track or cap the user's LLM spend. A user with their own API keys could still rack up costs on the provider side, and the application has no visibility into or control over that spend. For users using shared API keys, an attacker could drain the shared budget. **Perspective 4:** The POST /chat/:chatId/generate-title endpoint calls completeText (an LLM API) without any rate limiting or cost controls. An attacker could call this endpoint repeatedly, each time incurring an LLM API call to generate a short title. While each call is cheap, unlimited calls add up.

**Perspective 1:** The credit reset logic is implemented entirely on the client side. The function `loadProfile` checks if `credits_reset_date` has passed and resets `message_credits_used` to 0 locally, then updates the database in the background. A user can manipulate their local clock, clear localStorage, or block the background update to prevent the database from being updated, effectively resetting their credits without the server knowing. Additionally, the `MONTHLY_CREDIT_LIMIT` is set to 999999 (temporarily unlimited), which means the credit system is effectively non-functional and provides no real rate limiting. **Perspective 2:** The `incrementMessageCredits` function reads the current `messageCreditsUsed` from local state, increments it, and then updates the database. This is a classic read-modify-write race condition. If a user sends multiple concurrent requests, multiple increments can read the same value from the database, each incrementing it by 1, but the final value in the database will only reflect one increment instead of all. This allows a user to send many messages while only being charged for one. The check `if (profile.creditsRemaining <= 0)` is also client-side and can be bypassed by manipulating local state. **Perspective 3:** The `claude_api_key` and `gemini_api_key` are fetched from the database and stored in client-side state (`UserProfile`). These keys are then sent to the server on each API call. A malicious user could inspect the network traffic or client-side state to steal another user's API keys if they can somehow access their profile data. More importantly, the keys are stored in plain text in the database and transmitted to the client, violating best practices for secret management. **Perspective 4:** If the `user_profiles` table query fails (e.g., due to a database error or the profile not existing), the code creates a fallback profile with `messageCreditsUsed: 0` and `creditsRemaining: 999999`. This means any database error or missing profile grants the user unlimited credits. An attacker could potentially trigger a database error to get unlimited credits.

**Perspective 1:** The document_versions table has no RLS policies. Since it contains storage_path references to S3 objects, an attacker could enumerate version IDs to access any tenant's document content. **Perspective 2:** The chat_messages table has no RLS policies. Chat messages contain the full conversation history including document content and analysis, which could expose sensitive data across tenants. **Perspective 3:** The tabular_cells table has no RLS policies. It contains extracted data from documents including summaries, flags, and reasoning, which could expose sensitive analysis across tenants. **Perspective 4:** The document_edits table has no RLS policies. It contains the full text of deleted and inserted content from tracked changes, which could contain sensitive information from any tenant. **Perspective 5:** The workflow_shares table has no RLS policies. It contains email addresses and sharing permissions, which could leak information about which users have access to which workflows across tenants. **Perspective 6:** The tabular_review_chats and tabular_review_chat_messages tables have no RLS policies. These contain chat conversations about tabular reviews, which could expose sensitive analysis across tenants. **Perspective 7:** The project_subfolders table has no RLS policies. An attacker could enumerate folder structures across projects to discover document organization patterns of other tenants. **Perspective 8:** The hidden_workflows table has no RLS policies. It tracks which built-in workflows each user has hidden, which could leak user preferences across tenants.

The chatTools module imports createServerSupabase and uses it for all database operations including document reads, version loading, and edit persistence. The server-side client uses the service role key, bypassing RLS. None of the queries in this file include tenant_id or project_id filters to ensure data isolation between tenants.

**Perspective 1:** The DELETE /user/account endpoint uses the Supabase service role key (db.auth.admin.deleteUser) to delete users. This is a privileged operation that should require additional verification beyond just being authenticated. If an attacker gains access to a user's session token, they can permanently delete the account with no additional confirmation step beyond the client-side confirmation dialog. **Perspective 2:** User deletion functionality exists without additional verification steps. If an attacker gains access to the service role key or exploits an authentication bypass, they could delete users at will. This is particularly dangerous in a containerized environment where the service role key might be more accessible.

**Perspective 1:** The function getUserFromRequest() uses NEXT_PUBLIC_SUPABASE_PUBLISHABLE_DEFAULT_KEY (the anon/public key) to verify Supabase JWT tokens. The anon key cannot verify tokens — it's meant for client-side use. This means token verification will always fail or behave incorrectly, potentially allowing unauthenticated requests to pass through. **Perspective 2:** The environment variable NEXT_PUBLIC_SUPABASE_PUBLISHABLE_DEFAULT_KEY is used for server-side token verification. The 'NEXT_PUBLIC_' prefix in Next.js means this variable is exposed to the browser. The anon key is meant to be public, but using it for authentication verification is a security anti-pattern. **Perspective 3:** The code uses process.env.NEXT_PUBLIC_SUPABASE_URL! and process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_DEFAULT_KEY! with non-null assertion. If these are not set, the application will crash or use undefined values. There is no validation or error handling for missing environment variables.

getUserFromRequest 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 cannot properly verify tokens server-side. This may lead to incorrect validation results, potentially accepting invalid tokens or rejecting valid ones.

**Perspective 1:** The POST /projects/:projectId/chat endpoint initiates an LLM streaming response for project-specific chats. There is no rate limiting on this endpoint, allowing an attacker to make unlimited requests and incur significant costs or exhaust API quotas. **Perspective 2:** Similar to the chat endpoint, the project chat endpoint accepts messages without validation. Additionally, it accepts displayed_doc and attached_documents fields that could be manipulated to reference documents the user should not have access to.

**Perspective 1:** The loadActiveVersion and loadCurrentVersionBytes functions fetch document versions without verifying that the requesting user has access to the document's project. An attacker could enumerate document IDs to read any tenant's document versions. **Perspective 2:** The runEditDocument function accepts a documentId and performs edits without verifying that the document belongs to a project the user has access to. The function uses the server-side Supabase client which bypasses RLS. **Perspective 3:** The generateDocx function creates new documents in the database using the server-side Supabase client. The document is associated with a user_id but there is no verification that the user has access to the specified project_id. An attacker could create documents in any project.

The download endpoint at GET /download/:token accepts a signed token and resolves the file path, but does not verify that the requesting user belongs to the same tenant as the document owner. The `ensureDocAccess` function checks document-level access but does not enforce tenant-level isolation. A user from Tenant A could potentially access a document from Tenant B if they have a valid download token or if the token can be forged/leaked.

The GET /tabular-review endpoint returns all reviews accessible to the user, including full cell content with document extractions. Combined with the GET /tabular-review/:reviewId endpoint which returns all cells and documents for a review, an attacker with access to a single review can enumerate all documents and their extracted content. There is no pagination or rate limiting on these endpoints, allowing bulk exfiltration of all review data across all accessible projects.

Cross-chunk interaction detected. This finding interacts with confirmed threat [2] via data_flow. Interaction chain: Plaintext API keys in database (CANDIDATE-345) are directly accessible via chat tools (CONFIRMED-2) that use server-side client without tenant scoping, enabling key theft Original finding: 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.

Cross-chunk interaction detected. This finding interacts with confirmed threat [36] via data_flow. Interaction chain: Plaintext API keys in database (CANDIDATE-345) can be exfiltrated via service role client (CONFIRMED-36) that bypasses RLS Original finding: 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.

Cross-chunk interaction detected. This finding interacts with confirmed threat [8] via config. Interaction chain: No application-level rate limiting (CANDIDATE-352) directly enables unbounded LLM calls via chat streaming endpoint (CONFIRMED-8) Original finding: **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

Cross-chunk interaction detected. This finding interacts with confirmed threat [11] via config. Interaction chain: No application-level rate limiting (CANDIDATE-352) directly enables unbounded LLM calls via project chat endpoint (CONFIRMED-11) Original finding: **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

Cross-chunk interaction detected. This finding interacts with confirmed threat [12] via config. Interaction chain: No application-level rate limiting (CANDIDATE-352) enables mass data exfiltration via tabular review API (CONFIRMED-12) Original finding: **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

Cross-chunk interaction detected. This finding interacts with confirmed threat [2] via data_flow. Interaction chain: Email normalization bypass in access control (CANDIDATE-354) combined with chat tools lacking tenant scoping (CONFIRMED-2) allows cross-tenant document access Original finding: 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.

Cross-chunk interaction detected. This finding interacts with confirmed threat [2] via data_flow. Interaction chain: Unicode normalization bypass in shared access (CANDIDATE-356) combined with chat tools lacking tenant scoping (CONFIRMED-2) enables cross-tenant data access Original finding: **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 th

Cross-chunk interaction detected. This finding interacts with confirmed threat [9] via config. Interaction chain: Weak default signing secret for download tokens (CANDIDATE-372) makes the token forgery attack in CONFIRMED-9 trivially exploitable Original finding: **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.

Cross-chunk interaction detected. This finding interacts with confirmed threat [9] via config. Interaction chain: Weak default signing secret (CANDIDATE-373) enables forging download tokens (CONFIRMED-9) to access any document without tenant verification Original finding: 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.

Cross-chunk interaction detected. This finding interacts with confirmed threat [9] via config. Interaction chain: Weak fallback secret in containers (CANDIDATE-374) makes download token forgery (CONFIRMED-9) exploitable in production deployments Original finding: **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 forgin

Cross-chunk interaction detected. This finding interacts with confirmed threat [9] via data_flow. Interaction chain: Missing input validation on path/filename in signDownload (CANDIDATE-377) allows attackers to forge tokens (CONFIRMED-9) for arbitrary file paths Original finding: **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.

Cross-chunk interaction detected. This finding interacts with confirmed threat [4] via data_flow. Interaction chain: Unvalidated model parameter (CANDIDATE-382) combined with no cost controls (CONFIRMED-4) allows attacker to specify expensive models for denial of wallet Original finding: **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

Cross-chunk interaction detected. This finding interacts with confirmed threat [4] via data_flow. Interaction chain: Unvalidated model parameter in Gemini (CANDIDATE-385) combined with no cost controls (CONFIRMED-4) enables cost escalation attacks Original finding: **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 uninte

Cross-chunk interaction detected. This finding interacts with confirmed threat [4] via data_flow. Interaction chain: Unbounded iteration loop in Gemini streaming (CANDIDATE-387) combined with no max_tokens (CONFIRMED-4) creates infinite cost attack vector Original finding: 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.

Cross-chunk interaction detected. This finding interacts with confirmed threat [22] via shared_state. Interaction chain: Backend R2 credentials from env vars (CANDIDATE-390) are the same credentials exposed in frontend (CONFIRMED-22), confirming credential exposure is systemic Original finding: 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.

Cross-chunk interaction detected. This finding interacts with confirmed threat [3] via data_flow. Interaction chain: Storage key construction with unsanitized filenames (CANDIDATE-392) combined with document version loading lacking tenant verification (CONFIRMED-3) enables path traversal to other tenants' documents Original finding: 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).

Cross-chunk interaction detected. This finding interacts with confirmed threat [2] via data_flow. Interaction chain: User model settings loaded without validation (CANDIDATE-401) combined with chat tools lacking tenant scoping (CONFIRMED-2) allows model injection attacks Original finding: 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.

Cross-chunk interaction detected. This finding interacts with confirmed threat [2] via data_flow. Interaction chain: Plaintext API keys in database (CANDIDATE-402) combined with chat tools using server-side client without tenant scoping (CONFIRMED-2) enables key theft Original finding: **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

Cross-chunk interaction detected. This finding interacts with confirmed threat [6] via config. Interaction chain: JWT verification using service role key (CANDIDATE-403) is the same mechanism as CONFIRMED-6, confirming the pattern of using privileged keys for auth Original finding: 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.

Cross-chunk interaction detected. This finding interacts with confirmed threat [6] via config. Interaction chain: Auth middleware using service role key (CANDIDATE-406) is the same vulnerability as CONFIRMED-6, confirming the pattern Original finding: **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

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.

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 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.

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 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.

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.

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.

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 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 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.

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 Claude LLM integration uses user-controlled API base URLs in fetch requests without validation, allowing SSRF attacks.

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 `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.

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 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 `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.

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.

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.

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

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.

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.

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 tabular route uses user-controlled API base URLs in fetch requests without validation, allowing SSRF attacks.

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.

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.

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.

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 `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 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.

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.

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 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 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.

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.

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 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 `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.

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 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.

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.

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_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.

**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.

**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.

**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.

**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 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.

**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:** 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 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.

**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 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.

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 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).

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.

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.

**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 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 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 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.

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 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 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 `/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.

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.

**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.

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.

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:** 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.

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 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.

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 `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 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.

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 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 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.

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.

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.

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.

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-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.

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.

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.

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.

**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 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.

**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 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.

**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.

**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.

**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.

**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.

**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:** 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.

**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.

**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 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.

**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.

**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:** 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.

**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.

**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.

**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 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.

**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:** 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:** 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.

**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:** 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.

**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 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.

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.

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 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.

**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 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 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 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 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.

**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.

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 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.

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.

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 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 `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 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 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 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.

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.

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 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.

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.

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.

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 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.

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.

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.

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.

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.

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.

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 '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.

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 `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.

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.

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 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 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.

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:** 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.

**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.

**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.

**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 `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.

**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.

**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.

**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.

**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:** 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.

**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.

**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:** 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.

**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:** 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.

**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.

**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 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 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 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.

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 `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.

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 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.

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.

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.

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 `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.

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 `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:** 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.

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.

**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.

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 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 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.

**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.

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 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 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.

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.

**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.

**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 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.

**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.

**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 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.

**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.

**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.

**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 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 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 `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.

**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.

**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 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:** 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.

**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.

**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.

**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 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.

**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.

**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.

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.

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 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.

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 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.

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 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.

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.

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.

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.

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 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.

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.

**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.

**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.

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.

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.

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 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 `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 `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 `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 `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.

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.

**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.

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 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.

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 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.

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 CORS configuration allows any origin to access the API. This can expose sensitive endpoints to unauthorized third-party websites.

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 global error handler logs the full error object (including stack trace and digest) to the browser console via console.error. This exposes internal implementation details, file paths, and potentially sensitive data to any user who opens the developer tools.

**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.

**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.

**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.

**Perspective 1:** The API_BASE constant falls back to http://localhost:3001 when NEXT_PUBLIC_API_BASE_URL is not set. In production, this will cause the frontend to attempt connections to a local server, which will fail and may leak internal network information. This is a configuration issue that should be resolved by ensuring the environment variable is properly set in all deployment environments. **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 function logs the authenticated user's email to the console with `console.log('[Auth] User authenticated: ${user.email}')`. In production, this could leak user email addresses in server logs, which may be accessible to unauthorized personnel or through log aggregation services. **Perspective 2:** The token verification function logs the user's email to the browser console. This exposes user email addresses to anyone with access to the browser's developer tools, which is a privacy concern. **Perspective 3:** The token verification process logs the user's email to the browser console. This exposes potentially sensitive information (email addresses) in the client-side console, which could be viewed by anyone with access to the browser's developer tools.

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 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.

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 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 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 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.

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.

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.

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.

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 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.

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 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.

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.

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.

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.

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 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.

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.

**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.

Document version uploads lack audit logging. There is no record of when a user uploaded a new version of a document, the version name, or the result.

The AddColumnModal component accepts user-provided column names and prompts without sanitization. These values are later sent to the backend and rendered in various contexts. Column names are rendered as text in the UI and could contain XSS payloads if not properly handled.

The TRChatPanel component receives apiKeys (claudeApiKey, geminiApiKey) from the UserProfile context and passes them to isModelAvailable(). This exposes the user's API keys to client-side JavaScript, making them vulnerable to XSS attacks.

Tabular review chat operations (create, load, delete, send messages) lack client-side audit logging. There is no record of user interactions with the chat system for compliance or debugging purposes.

The formatCellForExport function removes citation markers but does not sanitize cell content for potential formula injection in Excel. Cell content starting with '=', '+', '-', or '@' could be interpreted as formulas when opened in Excel, leading to potential data exfiltration or code execution.

Tabular review export to Excel lacks audit logging. There is no record of when a user exported review data, which review, or how many documents were included.

Workflow execution (starting a chat or creating a review from a workflow) lacks audit logging. There is no record of which workflow was used, by whom, with which documents, or when.

The `WFEditColumnModal` accepts user input for `name` and `prompt` fields and sends them directly to the backend via `onSave` without any sanitization or validation. While the backend stores these values, they are later rendered unsanitized in `WFColumnViewModal.tsx` (via ReactMarkdown) and potentially other components. This creates a stored XSS vector through the column configuration data.

The global error page displays a generic message but the error object with digest is logged to console. In production, error details should not be exposed to end users as they may reveal internal application structure.

The useFetchDocxBytes hook logs documentId, versionId, refetchKey, and cache hit status to the console. This exposes internal caching behavior and document versioning details.

The API base URL falls back to 'http://localhost:3001' when NEXT_PUBLIC_API_BASE_URL is not set. This transmits session tokens over unencrypted HTTP in development environments.

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

The signup form only enforces a minimum password length of 6 characters, which is below current security best practices. This allows users to set weak passwords that are vulnerable to brute force attacks.

The auth utility logs user email on successful authentication via console.log. While this is useful for debugging, it exposes user email addresses in server logs which could be accessed by unauthorized personnel or in log aggregation systems.

The createServerSupabase function imports the SUPABASE_SECRET_KEY (service role key) in a frontend file. If this file is bundled or exposed, the service role key could be leaked, granting full database access.

**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 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.

**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.

**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.

**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.

**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.

**Perspective 1:** The useDocumentVersions hook uses 'http://localhost:3001' as fallback for API calls. This could expose document version data over unencrypted HTTP. **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 document version management, 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.

**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.

**Perspective 1:** The login form displays error messages directly from the Supabase auth response (e.g., 'Invalid login credentials' vs 'User not found'). This allows attackers to enumerate valid email addresses by observing different error messages for registered vs unregistered users. **Perspective 2:** The login form has no client-side or server-side rate limiting. An attacker can perform unlimited brute-force password attempts against any user account without throttling. **Perspective 3:** The login flow only requires email and password. There is no support for multi-factor authentication (MFA), leaving accounts vulnerable to credential theft and password reuse attacks. **Perspective 4:** The login form does not enforce any password complexity requirements. While this is a registration concern, weak passwords accepted at signup can be brute-forced at login. The application should enforce minimum password strength.

**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.

**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.

**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 DisplayWorkflowModal allows users to execute workflows without verifying they have permission to access the underlying documents or create reviews. SOC 2 requires authorization checks before executing actions. **Perspective 2:** Workflow execution (creating reviews or starting chats) lacks audit logging. SOC 2 requires logging of system changes and actions.

**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.

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 `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 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 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.

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 multer upload middleware only limits file size but does not validate file type, MIME type, or file extension. Any file type can be uploaded.

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 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 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.

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.

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 /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 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 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 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.

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.

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.

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 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 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.

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.

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.

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.

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 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.

The autoGeneratePrompt function sends column names to an external API without sanitization. This could expose sensitive data to third-party LLM providers. HIPAA requires business associate agreements and data minimization.

**Perspective 1:** The AddNewTRModal allows selecting unlimited documents for a tabular review. Each document triggers LLM processing when 'Run' is clicked, leading to unbounded costs. **Perspective 2:** The AddNewTRModal component allows users to select an unlimited number of documents for a tabular review. Each selected document triggers LLM processing for every column in the review. An attacker could select hundreds of documents, each incurring LLM API costs proportional to the number of columns.

Tabular review chat messages are stored but there is no audit trail for who accessed or viewed specific chat interactions. SOC 2 requires monitoring of access to sensitive data.

The TRTable component renders an unlimited number of columns. Each column triggers an LLM call per document when generating, leading to unbounded costs. An attacker can add many columns to inflate costs.

Operations like adding/removing documents, modifying columns, and running generation on tabular reviews are not audited. There is no record of who made changes to review configurations or when documents were added/removed.

The getPresetTabularPrompt function uses user-provided column titles to match against regex patterns and then generates prompts containing the title. The title is not sanitized before being included in the prompt, which could lead to prompt injection if the title contains malicious instructions.

The API client does not log requests or responses for audit purposes. SOC 2 requires logging of API access for monitoring and incident response.

The login page displays the error message returned from Supabase authentication. Depending on the specific error, this could reveal whether an email exists in the system (e.g., 'Invalid login credentials' vs 'User not found'), enabling user enumeration attacks.

The `processFiles` function converts DOCX files to text on the client side without size limits. Large files could cause browser memory exhaustion or hang the UI thread.

The frontend storage utility mirrors the backend's R2 storage implementation without client-side encryption. Files are uploaded and downloaded as raw bytes without any application-level encryption. This exposes sensitive legal document content to the storage provider and potential bucket misconfigurations.

**Perspective 1:** The signup form enforces a minimum password length of only 6 characters with no complexity requirements (uppercase, lowercase, digits, special characters). This makes user accounts vulnerable to brute-force and dictionary attacks. The Supabase default password policy may also be weak. **Perspective 2:** The signup form does not check the chosen password against known breached passwords (e.g., via Have I Been Pwned API or similar). Users may select passwords that have been exposed in previous data breaches, making credential stuffing attacks effective. **Perspective 3:** The signup form does not display a password strength indicator to guide users toward stronger passwords. This reduces user awareness of password security best practices. **Perspective 4:** The confirm password field only validates on form submission. Real-time mismatch feedback would improve user experience and reduce signup friction. **Perspective 5:** The signup page does not provide a link to account recovery or password reset options. Users who forget their password may have difficulty regaining access.

**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 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.

**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.

**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.

**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.

**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.

**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 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.

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 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.

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).

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 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.

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 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.

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.

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.

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 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 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 full error object to the console on stream errors. This could expose internal implementation details, stack traces, and potentially sensitive data.

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 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.

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 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.

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 `/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.

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.

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 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.

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 `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 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 `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.

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.

**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.

**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 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 `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 allows uploading new document versions without verifying the user's authorization to modify the document. SOC 2 requires access controls for data modification.

The highlightQuote function sets innerHTML with user-controlled quote text without proper sanitization, which could lead to DOM-based XSS if the quote contains malicious HTML.

The `getProject(projectId)` call in the AddNewTRModal fetches project data including documents by project ID. If the backend does not verify tenant membership, a user could pass another tenant's project ID and access their documents. The project selection dropdown shows all projects returned by `listProjects()` without filtering by tenant.

console.log(tags) in TREditColumnMenu logs the tags array, which may contain user-defined labels or sensitive terms. This could be captured by browser extensions or error monitoring.

The code exports data to Excel without sanitizing cell content. If cell values contain formulas starting with =, @, +, -, or other Excel formula prefixes, they could be executed when the user opens the spreadsheet. This is a classic CSV/Excel injection vulnerability.

The prompt generator creates prompts that may contain sensitive data from document analysis without classification or sanitization. HIPAA requires protection of PHI in all processing.

The `ShareWorkflowModal` allows a user to share a workflow with other users by email. There is no visible server-side check that the current user owns the workflow or has permission to share it. The `shareWorkflow` API call could potentially be exploited to grant access to workflows the user doesn't own.

The error page title includes the application name 'Mike', which helps attackers identify the specific software being used. Combined with other fingerprinting data, this can help attackers find known vulnerabilities.

The `useFetchDocxBytes` hook caches document bytes in a module-level Map without validating that the current user still has access to the document. If a user's access is revoked, they could still access cached document bytes until the cache is cleared or the page is refreshed.

The `useFetchSingleDoc` hook makes direct fetch calls to the backend API. If the auth token is invalid or expired, the error is caught generically as 'Failed to load document' without proper handling.

The NEXT_PUBLIC_API_BASE_URL environment variable falls back to 'http://localhost:3001' in client-side code. If this is not properly configured in production, API requests could be sent over unencrypted HTTP, exposing authentication tokens and document data in transit.

**Perspective 1:** The signup page does not implement any rate limiting or CAPTCHA protection. This could allow automated account creation attacks, credential stuffing, or abuse of the signup flow. **Perspective 2:** The signup and login flows do not implement account lockout mechanisms after failed attempts. This could allow attackers to brute force passwords or enumerate valid email addresses.

Errors during user profile creation are logged via console.log. While this is a client-side log, it could expose information about the authentication flow or API endpoint structure to anyone with browser developer tools open.

The NEXT_PUBLIC_API_BASE_URL environment variable falls back to 'http://localhost:3001' in client-side code. If not properly configured in production, authentication tokens could be sent over unencrypted HTTP.

When the automatic credit reset fails, the error is logged to the console via console.error. This exposes database operation details.

When token validation fails, the error message from Supabase is logged to the console. This may leak details about why authentication failed (e.g., expired token, invalid signature), which helps attackers understand the auth mechanism.

The NEXT_PUBLIC_SUPABASE_PUBLISHABLE_DEFAULT_KEY (anon key) is used in client-side code. While anon keys are designed to be public, they should still be protected by RLS policies. If RLS is misconfigured, this key could allow unauthorized data access.

**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.

**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.