🛡️ QAstell Security Audit Report

Links that open in a new tab/window without rel="noopener" allow the destination page to access the originating page via window.opener, enabling tabnabbing attacks.

Violations

Links with javascript: URLs execute code when clicked, which can be exploited for XSS if the URL content is user-controlled.

Forms that modify state (POST, PUT, DELETE) should include a CSRF token to prevent cross-site request forgery attacks where malicious sites submit requests on behalf of authenticated users.

Violations

Sensitive input fields (passwords, credit cards, SSN) that allow autocomplete may have their values cached by the browser, creating a security risk on shared computers.

Violations

Forms that submit data to HTTP (non-HTTPS) URLs expose the submitted data to interception via man-in-the-middle attacks.

Inline event handlers (onclick, onload, onerror, etc.) execute JavaScript directly in HTML attributes. These are common XSS vectors and violate Content Security Policy best practices.

Iframes loading external content without the sandbox attribute can execute scripts, submit forms, and potentially access the parent page. The sandbox attribute restricts these capabilities.

Iframes with both allow-scripts and allow-same-origin in the sandbox attribute can remove the sandbox via JavaScript, effectively bypassing all restrictions.

HTTPS pages that load resources over HTTP (mixed content) weaken the security of the connection. Active mixed content (scripts, iframes) is blocked by browsers, while passive mixed content (images, audio, video) may display warnings.

Content Security Policy (CSP) helps prevent XSS attacks by restricting resource loading. While CSP is best set via HTTP headers, a meta tag fallback can provide some protection.

Violations

The <base> tag changes how relative URLs are resolved. If a page allows user-controlled base tags (through injection), attackers can redirect relative URLs to malicious servers.

Pages without frame protection can be embedded in attacker-controlled iframes, enabling clickjacking attacks where users are tricked into clicking hidden elements.

Violations

External scripts and stylesheets loaded from CDNs or third-party sources should include integrity attributes to ensure the resource has not been tampered with.

Subresource Integrity hashes using SHA-256 are acceptable but SHA-384 or SHA-512 provide stronger security guarantees.

Email addresses visible in page source can be harvested by spam bots. Consider using obfuscation, contact forms, or JavaScript-based rendering.

API keys, tokens, or secrets appear to be exposed in page source or inline scripts. These credentials can be extracted and misused by attackers.

HTML comments are visible in page source and may contain sensitive information like TODO notes, credentials, internal paths, or debugging info that should not be exposed in production.

Inline event handlers within Shadow DOM can sometimes bypass Content Security Policy restrictions, creating XSS vulnerabilities even on CSP-protected pages.

Elements with open Shadow DOM (mode: "open") can have their shadow roots accessed via JavaScript. If the shadow DOM contains sensitive data or forms, this could be a security concern.

Forms inside Shadow DOM components may be overlooked when implementing CSRF protection, leaving them vulnerable to cross-site request forgery attacks.

Elements with id or name attributes that match global window/document properties can "clobber" these properties. If application code assumes these are native objects, it may lead to XSS or logic bugs.

Multiple elements sharing the same name attribute create an HTMLCollection. Attackers can inject elements to manipulate collections and bypass security checks.

Form elements with names like "action", "method", "submit" clobber the corresponding form properties. This can break form submission or redirect forms to attacker-controlled URLs.

Scripts loaded from advertising networks without Subresource Integrity are high-risk supply chain attack vectors. Ad networks are frequently targeted and have been compromised in the past.

Iframes loading content from advertising networks without sandbox restrictions can execute arbitrary scripts and potentially access parent page data.

Third-party scripts that use document.write() can inject arbitrary content into the page. Modern browsers may block these on slow connections, causing functionality issues.

Pages with many third-party scripts have increased attack surface. Each external script is a potential supply chain attack vector and data exfiltration point.

Tracking and analytics scripts on pages containing login forms, payment forms, or sensitive data may inadvertently leak user information to third parties.

Scripts loaded with non-JavaScript file extensions (.txt, .json, .html, etc.) may indicate misconfiguration. This can also be used to bypass WAF rules that only inspect .js files.

Stylesheets loaded with non-CSS file extensions may indicate misconfiguration. CSS can be used for data exfiltration attacks, so unusual sources should be reviewed.

Scripts with type attributes like "text/plain", "text/template", or custom types do not execute by default but contain code that could be activated by other scripts, potentially bypassing CSP.

Scripts loaded from data: URIs execute inline and can bypass some Content Security Policy configurations. They may also be used to hide malicious code.

URL query parameters containing __proto__, constructor, or prototype may exploit prototype pollution vulnerabilities if the URL is parsed with vulnerable code.

Inline scripts using Object.assign, spread operators, or deep merge with URL/cookie/postMessage data may be vulnerable to prototype pollution attacks.

Object.prototype has unexpected properties, indicating successful prototype pollution. This is a runtime check that detects if pollution has already occurred.

Inline scripts that modify Object.prototype, Array.prototype, or other built-in prototypes can cause unexpected behavior and security issues across all code on the page.

Links with URL parameters like "redirect", "return", "next", or "url" can be exploited for open redirect attacks if the target URL is not validated.

Forms with redirect parameters in action URL or hidden fields can be exploited for open redirect attacks, especially if combined with CSRF.

Meta refresh tags that redirect to external URLs can be exploited for phishing. Attackers may inject content that eventually redirects users to malicious sites.

Inline scripts that read from location (search, hash, href) and use it for redirects via location.href, location.assign, or window.open are vulnerable to open redirect.

If window.opener is accessible and not null, the opening page can be redirected by this page. This is a tabnabbing vector even on the opened page.

Scripts that add message event listeners without checking event.origin can receive malicious messages from any origin, leading to XSS or data manipulation.

Calling postMessage with "*" as the target origin allows any window to receive the message, potentially leaking sensitive data to malicious sites.

Scripts that handle postMessage events and use the data in dangerous sinks (innerHTML, eval, document.write) without sanitization are vulnerable to XSS.

localStorage persists indefinitely and is accessible to any JavaScript on the origin. Storing sensitive data (tokens, passwords, PII) makes it vulnerable to XSS attacks.

sessionStorage is accessible to any JavaScript on the origin. While it clears on tab close, storing sensitive data like auth tokens makes it vulnerable to XSS during the session.

Large JSON objects or plaintext data in localStorage/sessionStorage may contain sensitive information that should be encrypted or not stored client-side.

Scripts that access localStorage/sessionStorage without try-catch may fail in private browsing mode or when storage is full, potentially breaking functionality.

Elements with attributes containing unterminated quotes or suspicious URL patterns may be vulnerable to dangling markup injection, where subsequent page content is captured and sent to an attacker.

A <base> tag with an external href can hijack all relative URLs on the page, redirecting scripts, stylesheets, and links to an attacker-controlled server.

Forms that submit data to external domains could be exfiltrating sensitive information. This could be intentional (third-party services) or malicious (injected forms).

Meta refresh tags that redirect to external URLs with query parameters could be used to exfiltrate page content captured via dangling markup.

Noscript tags containing images, iframes, or other elements with external URLs could be used for dangling markup attacks against users with JavaScript disabled.

CSS @import rules loading stylesheets from external domains can be used to inject malicious styles or exfiltrate data via CSS selectors.

Inline styles using url() to load resources from external domains can be used for tracking, data exfiltration, or loading malicious content.

CSS attribute selectors on sensitive fields (password, credit card) combined with external resources can be used to exfiltrate form data character by character.

CSS expressions (expression()) and behaviors (behavior:url()) are legacy IE features that can execute JavaScript, creating XSS vulnerabilities.

Links containing internationalized domain names (IDN) with characters that visually resemble ASCII characters can be used for phishing (e.g., аpple.com using Cyrillic "а").

Right-to-left override characters (U+202E) can be used to disguise malicious URLs or file names by reversing text direction, making "exe.txt" appear as "txt.exe".

URLs containing null bytes (%00), backspace, or other control characters can be used to bypass security filters or exploit vulnerable parsers.

Zero-width characters (ZWSP, ZWNJ, ZWJ) in URLs or important text can hide malicious content or be used for watermarking/tracking.

Scripts that use innerHTML, outerHTML, or insertAdjacentHTML with data from URL parameters, cookies, or storage are vulnerable to XSS attacks.

document.write and document.writeln can be exploited for XSS, especially when combined with user input. They also block page rendering.

eval(), Function(), setTimeout(string), and setInterval(string) can execute arbitrary code and are dangerous when used with user input.

Using querySelector/querySelectorAll with user-controlled input can lead to DOM clobbering exploitation or unintended element selection.

Template literals containing user input that are inserted into the DOM via innerHTML or similar can lead to XSS if not properly escaped.

Scripts attempting to register service workers from a different origin could indicate malicious activity. Service workers have significant power over network requests.

Service workers registered with root scope (/) can intercept all requests for the origin. This may be intentional but increases the impact of any service worker vulnerability.

Service workers require HTTPS to function (except on localhost). If the page is not served over HTTPS, service workers will fail to register.

Service worker code with patterns that intercept all requests, modify responses, or communicate with external servers could be malicious.

The Fullscreen API can be used for phishing by displaying fake UI elements that appear to be from the browser or OS. Elements like iframes or divs requesting fullscreen should be reviewed.

CSS pointer-events: none can be used to create invisible overlays that pass clicks through to underlying elements, enabling clickjacking attacks.

Elements with very low opacity positioned over other content can be used for clickjacking by making the user think they are clicking on visible elements.

Disabling text selection (user-select: none) on elements containing links or forms can prevent users from verifying URLs or content.

Cookies containing session tokens or authentication data that are accessible to JavaScript (no HttpOnly flag) are vulnerable to theft via XSS attacks.

Cookies set on HTTPS pages without the Secure flag can be transmitted over unencrypted HTTP connections if the user visits the HTTP version of the site.

Violations

Cookies without the SameSite attribute (or with SameSite=None) may be sent with cross-site requests, making them vulnerable to CSRF attacks.

Violations

Cookies set with a leading dot domain (e.g., .example.com) or root path (/) are accessible to all subdomains and paths, potentially exposing them to less secure parts of the site.

Violations

Cookies containing values that look like JWTs, API keys, or encoded credentials may be exposing sensitive data that should be handled server-side.

Using unencrypted WebSocket connections (ws://) on HTTPS pages exposes the WebSocket traffic to man-in-the-middle attacks, defeating the purpose of HTTPS.

WebSocket connections to different origins may expose data to third parties. Ensure cross-origin WebSocket connections are intentional and to trusted endpoints.

WebSocket connections that do not appear to include authentication tokens in the URL or initial message may be vulnerable to unauthorized access.

WebSocket messages used directly in innerHTML, eval, or similar sinks without validation can lead to XSS if the server sends malicious data or is compromised.

SVG elements can contain <script> tags or event handlers that execute JavaScript. Many sanitizers fail to properly handle SVG namespaces, creating mXSS vulnerabilities.

MathML elements can be used for namespace confusion attacks where elements are parsed differently than expected, bypassing sanitizers.

Deeply nested elements or unusual combinations (like noscript inside noscript, or template inside foreignObject) can cause parser confusion leading to mXSS.

Style tags inside SVG, MathML, or other foreign content can behave unexpectedly and may be used to inject CSS or escape to HTML context.

Using DOMParser to parse HTML and then inserting it into the document without sanitization can lead to XSS, as DOMParser does not sanitize content.

Detects JavaScript making requests to private IP ranges, which could be exploited via DNS rebinding

Detects signs that Host header may not be validated, enabling DNS rebinding attacks

Detects WebSocket connections without origin validation that could be exploited via DNS rebinding

Detects CORS configurations that could be exploited in conjunction with DNS rebinding

Detects string comparisons that may be vulnerable to timing attacks

Detects early return patterns in authentication code

Detects usage of high-resolution timing APIs

Detects patterns where array iteration could leak length

Detects responses that may be cached without proper Vary header

Violations

Detects reflection of headers typically unkeyed in caches

Detects potentially dangerous cache-control configurations

Detects URL parameter reflection that could enable cache poisoning

Detects GET requests with body data that could confuse caches

Detects references to cloud services vulnerable to subdomain takeover

Detects JavaScript references to subdomains that could be taken over

Detects external resources that could indicate takeover opportunity

Detects mail service subdomains vulnerable to takeover

Detects CORS with credentials that may have wildcard origin

Detects patterns that may accept null origin

Detects patterns indicating origin reflection

Detects overly permissive CORS preflight handling

Detects CORS requests to internal network

Detects manual Content-Length header manipulation

Detects Transfer-Encoding header usage

Detects patterns that could create ambiguous HTTP requests

Detects patterns exploiting HTTP/2 to HTTP/1.1 translation

Detects JSON.parse with reviver function that could execute code during parsing

Detects use of Function constructor which can execute arbitrary code

Detects eval usage for parsing data, which enables code execution

Detects jQuery methods that can deserialize untrusted data unsafely

Detects postMessage handlers that parse data without origin validation

Detects time-of-check-time-of-use patterns that could be exploited

Detects shared state access without proper synchronization

Detects forms or actions vulnerable to double-submit race conditions

Detects parallel fetch calls that might create race conditions

Detects localStorage operations that could race across tabs

Detects pages using sensitive features without Permissions Policy restrictions

Detects iframes with overly permissive allow attribute

Detects media autoplay usage that should be controlled by policy

Detects access to motion sensors that could be used for fingerprinting

Detects document.domain usage which is deprecated and weakens security

Detects Math.random usage in security-sensitive contexts

Detects hardcoded keys, IVs, or secrets in JavaScript

Detects usage of deprecated or insecure cryptographic APIs

Detects client-side password hashing with weak algorithms

Detects potential issues with Web Crypto API usage

Detects regex patterns vulnerable to catastrophic backtracking

Detects regex with unbounded repetition applied to user input

Detects email validation regex that may be vulnerable to ReDoS

Detects URL validation regex that may be vulnerable to ReDoS

Detects RegExp created from user-controlled input

Detects references to package names that appear to be internal/private

Detects CDN references to packages that may be vulnerable to confusion attacks

Detects dynamic imports that could be vulnerable to dependency confusion

Detects scoped packages that could be hijacked if scope is not registered

Detects URL parameters being passed to fetch/XHR requests

Detects user input being used to construct request URLs

Detects usage of proxy or redirect endpoints that could be exploited

Detects webhook configuration that could be abused for SSRF

Detects media elements with URLs from user input

Detects access to window.opener which can enable tabnabbing

Detects window.open calls that may expose opener reference

Detects attempts to access cross-origin frames

Detects postMessage being sent to window.opener

Detects links that open in new tab with sensitive URL parameters

Detects file references that could be polyglot files

Detects JSONP endpoints which can have content-type confusion

Detects data: URLs that could contain executable content

Detects blob: URLs that could be used for XSS

Detects patterns that could be exploited via MIME sniffing

JavaScript bundles contain references to admin panels, debug endpoints, or internal routes. Attackers can discover these by searching the source code.

Hidden form fields containing user IDs, role information, prices, or other sensitive values can be modified by attackers using browser dev tools or intercepting proxies.

JavaScript source maps (*.map files) are referenced, which could expose original source code, internal paths, and potentially sensitive comments or logic to attackers.

Form controls use client-side only validation (disabled buttons, maxlength, pattern) without apparent server-side enforcement. Attackers can bypass these by modifying the DOM or intercepting requests.

JavaScript contains hardcoded credentials, coupon codes, encryption keys, or other secrets that should not be exposed in client-side code.

Page contains references to debug endpoints, stack trace information, or development tools that should not be accessible in production.

The page loads JavaScript libraries with known security vulnerabilities. These should be updated to patched versions.

Violations

PHP error messages are visible in the page, revealing server paths, code structure, and potentially sensitive configuration details. This indicates display_errors is enabled in production.

The page appears to be a phpinfo() output, which reveals extensive information about PHP configuration, server environment, and installed modules.

PHP session ID (PHPSESSID) is passed in the URL, making it vulnerable to session fixation attacks, referrer leakage, and browser history exposure.

ASP.NET error page (YSOD - Yellow Screen of Death) is visible, revealing stack traces, source code snippets, and server configuration details.

ASP.NET ViewState is present and may be vulnerable to tampering or deserialization attacks if not properly protected with MAC validation.

ASP.NET version information is disclosed in page content or meta tags, helping attackers identify potential vulnerabilities for that version.

Java exception details or stack traces are visible in the page, revealing class names, method signatures, and potentially sensitive internal paths.

Java session ID (JSESSIONID) is present in URLs, making it vulnerable to session fixation, referrer leakage, and URL sharing attacks.

WordPress version is disclosed through meta tags, script URLs, or readme files. This helps attackers identify known vulnerabilities for that version.

References to sensitive WordPress paths like wp-config.php, xmlrpc.php, or debug.log indicate potential security risks.

A content management system (CMS) has been detected. This information helps identify potential platform-specific vulnerabilities.

Angular is running in development/debug mode, which provides detailed error messages and debugging information that should not be exposed in production.

React is running in development mode, which is slower and includes extra warnings. Production builds should use minified React.

Vue.js is running in development mode, which includes additional warnings and Vue DevTools support that should be disabled in production.

jQuery methods like .html(), .append(), .prepend(), .after(), .before(), and .replaceWith() can execute scripts when used with untrusted data.

Passing user-controlled input to jQuery selector $() can lead to XSS if the input contains HTML, as jQuery parses HTML strings.

Assigning user-controlled input to location.href, location.assign(), location.replace(), or window.open() can lead to open redirect vulnerabilities.

Using history.pushState() or history.replaceState() with user-controlled URLs can be used for phishing by spoofing the URL bar.

Inserting fetch() or XMLHttpRequest response data directly into innerHTML without sanitization can lead to XSS if the response contains malicious content.

JSONP requests where the callback parameter is derived from user input can lead to XSS if the callback name is not properly validated.

Creating script elements dynamically with user-controlled src URLs or content can lead to XSS or malicious script execution.

Using setAttribute() to set src, href, or event handler attributes with user-controlled values can lead to XSS or open redirect.

Invisible 1x1 pixel images or hidden images are commonly used for user tracking without consent. These can leak browsing data to third parties.

navigator.sendBeacon() is used to send data that persists even when the page unloads. This can be used for tracking or data exfiltration.

Iframes hidden via CSS (display:none, visibility:hidden, 0x0 size, off-screen positioning) can perform hidden actions like clickjacking, voting, or unauthorized transactions.

Links, buttons, or forms that are invisible or positioned off-screen can be used for clickjacking, hidden submissions, or SEO manipulation.

Violations

DNS prefetch and preconnect to external domains can leak browsing information and be used for tracking even if resources are never loaded.

RTCPeerConnection can expose real IP addresses even when users are behind VPNs or proxies. This is a significant privacy concern.

Scripts accessing multiple browser properties (screen size, plugins, fonts, WebGL, Canvas) together suggest device fingerprinting for tracking.

Canvas-based fingerprinting creates unique identifiers by rendering text/graphics and extracting pixel data. This enables cross-site tracking.

Scripts that write to the clipboard can replace copied content with malicious payloads, potentially leading to code injection when users paste.

CSS attribute selectors combined with background-image URLs can exfiltrate input values character by character without JavaScript.

Server technology, framework versions, or generator information exposed in meta tags or HTML comments helps attackers identify known vulnerabilities.

Scripts accessing navigator.geolocation can track user's precise physical location. This should only be used when clearly necessary and with user consent.

Scripts requesting notification permissions can be used for spam, phishing, or social engineering attacks via browser notifications.

The Battery Status API can be used for device fingerprinting. Battery level, charging status, and time create a semi-unique identifier.

The Vibration API can be abused for attention-grabbing malware, covert communication channels, or user annoyance attacks.

The Payment Request API initiates payment flows. Ensure it is only triggered by explicit user action and clearly displays payment details.

The Web Share API can share content to other apps. Ensure shared content is what users expect and not attacker-controlled.

The Web Bluetooth API can discover and connect to nearby Bluetooth devices. This poses privacy and security risks if misused.

The WebUSB API can access connected USB devices, potentially exposing sensitive hardware or enabling attacks on connected devices.

The Web Serial API can access serial ports, potentially communicating with industrial equipment, microcontrollers, or other sensitive devices.

Enumerating media devices (cameras, microphones) can be used for device fingerprinting by creating unique device ID lists.

AudioContext with oscillator and analyser nodes can create unique audio fingerprints for cross-site tracking.

Iterating through fonts and measuring text width to detect installed fonts creates a unique device fingerprint.

Accessing WebGL debug renderer info (WEBGL_debug_renderer_info) reveals GPU details that create unique device fingerprints.

window.name persists across page navigations and can be used as a covert channel to pass data between origins or exfiltrate information.

Meta refresh tags can redirect users without JavaScript, potentially to malicious sites. They can bypass some redirect protections.

The <base> tag changes the base URL for all relative links. An external base href can redirect form submissions and links to attacker-controlled servers.

The srcdoc attribute embeds HTML directly in an iframe. If user-controlled, this can lead to XSS without loading an external URL.

The Resource Timing API can leak information about cross-origin resources, potentially revealing user state or cached resources.

The Credential Management API can access stored credentials. Ensure it is used securely and only for legitimate authentication.

IndexedDB can store large amounts of data client-side. Ensure sensitive data is encrypted and properly managed.

WebView JavaScript bridges (Android addJavascriptInterface, iOS messageHandlers) can be exploited if the page is loaded in a vulnerable webview or if XSS occurs.

Links using intent://, custom schemes, or deep links can be exploited to launch apps with malicious parameters or bypass security controls.

Pages without proper viewport configuration may allow zooming attacks or tapjacking. user-scalable=no can prevent accessibility but may be required for security.

Scripts capturing touch events (touchstart, touchend, touchmove) on document or body level may be attempting tapjacking or UI redress attacks.

Access to device orientation and motion sensors can be used for fingerprinting, keystroke inference, or tracking user movements.

Links to app stores should be validated to ensure they point to legitimate apps. Attackers may redirect users to malicious apps.

References to file:// URLs may indicate the page expects to run in a webview with file access enabled, which can lead to local file theft.

Pages that handle deep linking should properly validate the source. Missing apple-app-site-association or assetlinks.json verification could allow link hijacking.

Password, credit card, and other sensitive inputs in pages loaded via webview could be intercepted by malicious apps through JavaScript injection.

Violations

Clipboard access on mobile devices can expose sensitive data like passwords, 2FA codes, or cryptocurrency addresses that users frequently copy.

Screen capture APIs (getDisplayMedia) can be used to record sensitive content displayed on the device.

WebGL can expose detailed GPU information (renderer, vendor, extensions) that creates a unique device fingerprint. This is commonly used for tracking.

Page creates WebGL or WebGL2 rendering contexts. While legitimate for 3D graphics, WebGL can be used for fingerprinting and may have security implications.

WebGPU is a modern graphics API that provides lower-level GPU access than WebGL. It can expose detailed hardware information and may have security implications.

Page requests access to camera, microphone, or screen capture. These are sensitive permissions that should only be requested when necessary.

Page interacts with cryptocurrency wallets (MetaMask, etc.). This can expose wallet addresses and may request transaction signing.

Page uses WebXR API for virtual or augmented reality. This can access device sensors, cameras, and spatial tracking data.

Page uses speech recognition or synthesis. Speech recognition can capture audio and may send it to external servers for processing.

Page uses animations that could be used for UI deception, such as moving elements, fake loading indicators, or visual misdirection.

Page uses Picture-in-Picture API which creates a floating video window. This could potentially be abused for UI spoofing attacks.

Page uses File System Access API which can read and write files on the local system. This is a powerful permission that should be used carefully.

Page requests access to MIDI devices. This can reveal connected musical instruments and controllers, contributing to device fingerprinting.

Page accesses connected gamepads. The specific controllers and their IDs can be used for device fingerprinting.

Page uses WebCodecs API for low-level video/audio encoding/decoding. This provides direct access to media codecs.

Page uses Web NFC API for near-field communication. NFC can read/write to contactless cards and tags.

Page uses Compression Streams API. While legitimate for reducing bandwidth, compression can also be used to efficiently exfiltrate data.

Page uses Background Sync API which can queue network requests to be sent when connectivity is restored, even after the page is closed.

URLs with unusual patterns (backslashes, null bytes, excessive encoding, protocol confusion) may attempt to exploit parser differences or bypass security controls.

Scripts that modify Object.prototype, Array.prototype, or use __proto__ may be attempting prototype pollution attacks that can lead to sandbox escape.

Geolocation API usage that may be excessive, automated, or combined with data exfiltration patterns.

Blob URLs created from user input or external data can be used to bypass CSP, create downloadable malware, or execute code in isolated contexts.

Web Workers can execute code in isolated contexts, potentially bypassing main thread security controls. Workers from blob URLs or with postMessage can be exploited.

High-resolution timing APIs and cross-origin timing measurements can leak sensitive information about other origins or enable Spectre-style attacks.

Code patterns that could rapidly allocate memory (infinite loops, recursive allocations, large arrays) may be attempting to crash the browser or cause DoS.