How to fix Inline Scripts Present?

inline-scripts-presentpage

Inline scripts are JavaScript code embedded directly in HTML using script tags without src attributes or event handler attributes like onclick. These scripts execute in the page context with full DOM access. Content Security Policy cannot distinguish between legitimate inline scripts and XSS payloads without additional mechanisms. Inline scripts prevent CSP deployment or require unsafe-inline which disables XSS protection. Moving scripts to external files or implementing CSP nonces resolves this constraint.

What’s wrong

The page contains script elements with inline code instead of external src references. Inline scripts appear between opening and closing script tags directly in HTML. Event handler attributes like onclick, onload, and onerror count as inline scripts. These scripts execute immediately when parsed. Content Security Policy cannot enforce restrictions on inline scripts without allowing all inline scripts via unsafe-inline or using nonces and hashes.

Why it matters

Inline scripts prevent effective XSS protection through Content Security Policy. CSP blocks script execution based on origin for external scripts. Inline scripts have no origin to evaluate. XSS attacks inject inline scripts into the HTML. A strict CSP that blocks inline scripts prevents these attacks. Allowing unsafe-inline to accommodate legitimate inline scripts also permits XSS payloads. The presence of inline scripts forces a choice between functionality and security. Removing inline scripts enables strong CSP without unsafe-inline.

The correct change

Move inline script code to external JavaScript files loaded via src attributes. Extract code from script tags into .js files served from the same origin or trusted CDNs. Replace event handler attributes with addEventListener calls in external scripts. Alternatively, implement CSP nonces by generating unique random tokens per response and adding them to both script tags and CSP script-src directives. Use hashes as a static alternative to nonces when response content is cacheable. The end state is no inline scripts without nonces or all inline scripts carrying valid CSP nonces.

Scope

This condition applies at the page level. Each HTML response may contain inline scripts. Templates and server-rendered pages often inject inline scripts for initialization and configuration. Third-party scripts sometimes inject inline code dynamically. Client-side frameworks may generate inline event handlers. Global resolution requires scanning all page generation paths and third-party integrations.

How to verify

• Validation confirms the condition is resolved:
• • No script elements with inline code between tags
• • All script elements have src attributes pointing to external files
• • No event handler attributes on HTML elements
• • If inline scripts remain, all have valid CSP nonce attributes
• • CSP script-src directive does not include unsafe-inline
• • Page functionality works with strict CSP enforced
• • Console shows no CSP violations for inline scripts

Takeaway

• Inline scripts prevent effective Content Security Policy XSS protection
• External scripts with src attributes allow origin-based CSP enforcement
• CSP nonces provide a secure alternative when inline scripts cannot be externalized
• Event handler attributes count as inline scripts and need conversion
• Removing inline scripts enables CSP without unsafe-inline

FAQ

Why are inline scripts considered less secure than external scripts?

Inline scripts cannot be distinguished from XSS payloads at the CSP enforcement level. Both are strings of JavaScript in HTML. External scripts have origins that CSP can evaluate. CSP allows scripts from trusted domains while blocking others. Inline scripts require either allowing all inline scripts or implementing per-script authorization through nonces or hashes. The lack of origin makes inline scripts harder to control.

What about inline scripts for configuration or initialization?

Move configuration to data attributes on HTML elements that external scripts read. Use script tags with type application/json containing configuration as JSON that JavaScript parses. Pass initialization data through API endpoints that JavaScript fetches. These patterns separate data from code and allow strict CSP. Configuration injection remains possible without executable inline scripts.

How do CSP nonces work with inline scripts?

The server generates a cryptographically random nonce for each response. The nonce appears in the CSP header and as a nonce attribute on legitimate script tags. Browsers only execute inline scripts with nonces matching the CSP header. XSS payloads lack the correct nonce and fail to execute. Nonces must be unique per response and unguessable. This mechanism allows specific inline scripts while blocking injected ones.

Should all inline scripts be converted simultaneously?

Not necessarily. Prioritize removing inline scripts from user-controlled content areas where XSS risk is highest. Convert inline scripts in templates under full control before addressing third-party integrations. Some third-party scripts inject inline code dynamically and require vendor changes or replacement. Progress on inline script removal enables incrementally stronger CSP policies.

Do inline styles have the same security implications?

Inline styles have different risk profiles. Inline CSS cannot execute JavaScript directly but can exfiltrate data through background-image URLs and other properties. CSP style-src controls inline styles similarly to script-src. Removing inline styles improves CSP posture but is less critical than removing inline scripts. Focus on scripts first as they present direct execution risk.

Can frameworks like React generate inline scripts?

Modern frameworks generally avoid inline scripts in production builds. React, Vue, and Angular bundle JavaScript into external files. Server-side rendering sometimes injects inline scripts for hydration state. Configure these frameworks to use nonces or move hydration data to JSON script tags. Framework upgrade to recent versions often improves inline script handling.

The fix

Enable strict Content Security Policy by eliminating inline scripts or implementing nonces

Done when: All JavaScript code exists in external files or inline scripts use valid CSP nonces

Do not

• Do not add unsafe-inline to CSP as a permanent solution
• Do not ignore event handler attributes when removing inline scripts
• Do not use predictable or static nonce values
• Do not leave inline scripts in user-controlled content areas

How to verify

• No script elements with inline code lacking nonces
• All scripts either external or properly nonced
• No event handler attributes on elements
• CSP enforces without unsafe-inline
• Console shows no inline script violations

Find every page with this

probeo monitors this continuously across every page of your site, and records which pages passed, which failed, and which it could not determine.