window.onerror handler catches synchronous errors
Why it matters
Third-party scripts — analytics, chat widgets, A/B testing tools — run in the same JavaScript context as your application. A synchronous error in any of them crashes the page if window.onerror is not configured. CWE-703 applies: failures in external code are exceptional conditions your app must handle. Without this handler, you have no visibility into crashes caused by vendor script updates, and users experience blank pages with no error surface in your error tracking dashboard.
Severity rationale
High because synchronous errors from third-party scripts silently crash the page with no diagnostic trail unless a global handler is in place.
Remediation
Register window.onerror early in your app's entry point or layout. Return true to suppress the default browser error dialog.
// app/layout.tsx or lib/error-handlers.ts (client-side only)
if (typeof window !== 'undefined') {
window.onerror = (message, source, lineno, colno, error) => {
reportError(error ?? new Error(String(message)), {
source,
lineno,
colno,
})
return true // suppress browser console error
}
}
Pair with unhandledrejection handler (see unhandled-promise-rejection) for full client-side coverage. The handler must forward to your error tracking service, not just console.error.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Error Resilience Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- cwe · CWE-703 — Improper Check or Handling of Exceptional Conditions
- iso-25010:2011 · reliability.fault-tolerance
Taxons
History
- 2026-04-18·v1.0.0·Initial import from error-resilience·automated