Content Security Policy

Core idea

Content-Security-Policy header

Security boundary

Treat input, network data and third-party code as untrusted until proven otherwise.

Performance boundary

Measure before optimizing, then remove unnecessary work.

Production habit

Use defaults that are safe, explicit and easy to review.

Safer pattern

Use this direction in real code.

Content-Security-Policy: default-src 'self'; script-src 'self'

Risky pattern

This version introduces security, performance or maintenance risk.

Content-Security-Policy: script-src * 'unsafe-inline' 'unsafe-eval'

Measure first

Performance work should start with numbers.

const start = performance.now();
runWork();
console.log(performance.now() - start);

Prefer explicit trust boundaries

Keep unsafe operations rare and visible.

function renderText(element, value) {
  element.textContent = value;
}

Never trust user input

Render untrusted values as text unless sanitized by a proven process.

Avoid string-to-code execution

eval and similar patterns expand the attack surface.

Understand browser security boundaries

CORS and CSP are server/browser policies, not client hacks.

Measure performance

Use browser tools and APIs before guessing.

Reduce main-thread work

Batch DOM reads and writes, debounce noisy events and avoid unnecessary loops.

Review dependencies and third-party scripts

Security and performance problems often enter through packages.

Production note

Production JavaScript should use CSP, safe DOM updates, measured performance and code review around risky APIs.

SEO note

A fast, stable page is easier for users and crawlers to process. Critical content should not depend on fragile client code.