No stack traces in errors

Verifies

No HTTP error response carries a stack trace, a formatted traceback or a raw exception, and no framework debug mode is switched on by a literal.

Inputs

Non-test code files of the checkout (JavaScript, TypeScript, Python, PHP) classified as browser or server code with the runtime criterion below, committed .env files (not the example variants), php.ini, .user.ini and .htaccess. A module that proves it runs inside a Web Worker (DedicatedWorkerGlobalScope, SharedWorkerGlobalScope, ServiceWorkerGlobalScope, WorkerGlobalScope, importScripts(), self.postMessage or self.onmessage), answers with postMessage() and holds no HTTP response sink is a BROWSER MESSAGE CHANNEL and is not analysed (the trace names it). Paths listed in excludes (test, spec and tmp files, __tests__, __mocks__, fixtures, test, tests and audit-scripts folders) are never analysed.

Decision rule

A file is judged SERVER only with proof of its own runtime or of the import graph: the language (Python, PHP), a `server-only` import or a `'use server'` directive, a location the framework declares as server (route.ts, middleware, pages/api, app/api, *.server.*, +server, wsgi/asgi), a Node built-in or server-only package, an HTTP response sink or a Lambda handler export, importing a module that is itself proven to run on a server, or a server folder by framework convention. It is judged BROWSER when it declares `'use client'` or imports `client-only`, when its code touches the DOM, a Web Worker scope, `new Worker(`, a React client hook or a browser-environment polyfill, when a client-declared file of the checkout imports it, when it sits in a browser folder by convention, or when it only uses a Web API the browser serves (`crypto.subtle`, `globalThis.crypto`, `CryptoKey`, `new Blob`, `atob`) with no server evidence at all. NEITHER is NOT server: the shared layer of a monorepo is never accused on a folder name, and the trace says the layer is unproven. `workers/` is not a server folder (a worker folder is a browser convention as often as a server one). The three response rules (a stack in the response, the whole exception forwarded, a traceback in the response) are applied only to a file that is proven server code or that writes an HTTP response: an error carrying its stack inside browser code (a React error boundary reporting to its own action, a component handing { name, message, stack } to a callback of the same page) crosses no network boundary and is not analysed, and the trace names the file. The debug-mode and development-middleware rules apply to every file and every configuration. A browser message channel (a Web Worker module answering with postMessage and holding no HTTP response sink) is never analysed: its receiver is the main thread of the same page, which already has that code, so a serialised error with its stack crosses no network boundary; a worker file that DOES write an HTTP response is analysed in full. Not applicable when the checkout has no server-side code. FAIL (HIGH) when a response includes err.stack, getTraceAsString() or traceback.format_exc(), when debug mode is a literal true (Django DEBUG = True in settings, Flask app.run(debug=True), FastAPI(debug=True), Laravel 'debug' => true, APP_DEBUG=true in a committed .env, PHP display_errors on, Express env development, Nest showErrorDetails), or when a development error page middleware (errorhandler, Whoops) is wired. Forwarding the raw exception object or its message to the client is MEDIUM (blocks in Extended suites). Debug values read from the environment or configuration never count. PASS when server code exists and no rule fired.

Type

deterministic

1.0.4: an error carrying its stack inside BROWSER code is not an HTTP error response. The three response rules (stack in the response, whole exception forwarded, traceback in the response) are applied only to a file that is proven server code OR that writes an HTTP response: a React error boundary that reports `error.stack` to its own report action, and a component that hands `{ name, message, stack }` to a callback of the same page, cross no network boundary and are not analysed (the trace names the file). A worker or browser file that DOES write an HTTP response keeps being judged in full. The debug-mode and development-middleware rules are unchanged. Same runtime criterion as the shared-layer fix: WHERE A FILE RUNS is decided from the FILE (and, when the file alone does not say, from the import graph of the checkout), never from a list of folder names of one particular repository, and a file whose server nature is UNPROVEN is never reported as server code. A monorepo has a SHARED layer — a package the browser bundle and the services both import — and the old rule read every ambiguous file as server: WebCrypto of the browser (`crypto.subtle` in a shared e2ee service that a client component imports) came out as "key generation in server code", once per product sharing the layer. The evidence is now, strongest first: the language (Python, PHP); a `server-only`/`client-only` import or a `'use server'`/`'use client'` directive; a location the framework declares as server (route.ts, middleware, pages/api, app/api, *.server.*, +server, wsgi/asgi); a browser runtime in the code (DOM member, Web Worker scope, `new Worker(`, a React client hook, a browser-environment polyfill such as fake-indexeddb or jsdom); a server runtime in the code (Node built-in, server-only package such as express/mongodb/winston/@aws-sdk, HTTP response sink, Lambda handler export); the IMPORT GRAPH (a module a client-declared file imports runs in the browser, a module that imports a server-proven module runs on a server); the folder convention (`workers/` is no longer one of them: a worker folder is a browser convention as often as a server one); a universal Web API of the browser with no server evidence at all; otherwise unproven, which is never server. Found by the attestation campaign of the platform (2026-09-25): 73 of the 252 high findings of every project were this one classification. (1.0.3: false positive of the attestation of platform/projects/fun (2026-09-24), fixed in the script: un módulo que demuestra correr dentro de un Web Worker (DedicatedWorkerGlobalScope, SharedWorkerGlobalScope, ServiceWorkerGlobalScope, WorkerGlobalScope, importScripts(), self.postMessage o self.onmessage), que responde con postMessage() y que no tiene NINGÚN sumidero de respuesta HTTP es un CANAL DE MENSAJES DEL NAVEGADOR y no se analiza (la traza lo nombra): su receptor es el hilo principal de la misma página, que ya tiene ese código, y el error serializado con su stack es lo que hace depurable un fallo dentro de un worker. Un fichero de worker que SÍ escribe una respuesta HTTP se sigue analizando entero. (1.0.2: never analyses temporary files (*.tmp.*; spec.excludes follows AUDITOR_ANALYSIS_EXCLUDES). (1.0.1: never analyses test, spec, fixture and mock paths nor the auditor's own scripts (spec.excludes = AUDITOR_ANALYSIS_EXCLUDES); a fixture-looking secret (sk_test_, example, dummy) in real code is LOW, informative; every model call stays under the engine prompt cap (spec.promptMaxChars = AUDITOR_AI_PROMPT_MAX_CHARS): assess mode sends the candidate set in parts and aggregates the verdicts (a HIGH in any part is a FAIL, an unsatisfied part is a FAIL).)))

The full script is disclosed on request in a read-only viewer (never published on GitHub); the attestation binds to this exact hash.