FSM Full Stack Masterclass
Platform under construction
JavaScript course badge

Security & Performance

Advanced

eval Risks

eval runs strings as code and turns data problems into code execution problems.

const actions = {
  save: () => saveSettings(),
  reset: () => resetSettings(),
};

actions[actionName]?.();

Security & Performance

eval Risks is part of shipping JavaScript responsibly.

eval runs strings as code and turns data problems into code execution problems.

Security and performance are not cleanup tasks at the end. They influence which APIs you choose, how you update the DOM and how much work runs on the main thread.

The goal is practical judgement: safe output, measured code, controlled permissions and browser work that does not punish the user.

Core idea

avoid eval()

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.

Examples

Safe and fast JavaScript is a design choice.

Prefer the safer production pattern

const actions = {
  save: () => saveSettings(),
  reset: () => resetSettings(),
};

actions[actionName]?.();

Avoid the risky shortcut

eval(actionName + "()");

Code patterns

Reusable examples for quick reference.

Use these examples as a practical reference for safer DOM updates, browser policies and performance habits.

Safer pattern

Use this direction in real code.

const actions = {
  save: () => saveSettings(),
  reset: () => resetSettings(),
};

actions[actionName]?.();

Risky pattern

This version introduces security, performance or maintenance risk.

eval(actionName + "()");

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;
}

Rules that matter

Production JavaScript needs boundaries.

Every script runs inside a browser, on a real device, with real data. That makes security and performance part of the feature.

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 thinking

Ship code users can trust.

Why does this matter?

Security bugs and slow interfaces both destroy trust. Users may not see the code, but they feel the consequences immediately.

Accessibility

Fast, stable JavaScript helps keyboard users, screen readers and users on lower-powered devices. Security UI also needs clear messages.

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.

Live code lab

Change the HTML, CSS or JavaScript and run the result.

The preview runs inside an isolated iframe. The JavaScript is placed inside the HTML editor for now, so every example stays together and remains easy to understand.

Mini assignment

Try this now.

  • Change the input or value and run the example again.
  • Explain which boundary is being protected.
  • Name one production check you would add.

Practice assignment

Do this before moving to the next topic.

  1. Find the risky line in the weak example.
  2. Rewrite it using the safer pattern.
  3. Add one measurement or review step before shipping.

Try it yourself

Experiment with eval Risks

Live preview

Self-check

Before you continue, prove that you understand eval Risks.

Advanced

Answer these before moving to the next security and performance lesson.

  1. What is the main risk in eval Risks?
  2. Which API or habit reduces that risk?
  3. What would you measure or review in production?
  4. How can this affect users directly?
  5. Why is the weak example dangerous or slow?

Senior audit upgrade

Extra production context for eval Risks.

String execution checklist

  • Avoid eval for application logic.
  • Treat the Function constructor as the same risk family.
  • Avoid string-based setTimeout and setInterval.
  • Prefer explicit functions, maps and parser logic.