Skip to content

node_00 - Node.js HOME

Node is not a language , it's a runtime
V8 engine stripped of the browser chrome , glued to libuv for async I/O , wrapped in a C++ layer that gives JavaScript filesystem access and network sockets and process control. That's it. That's Node. Ryan Dahl built it in 2009 because he wanted to push real-time updates to a web server without Apache threads eating all the RAM , and somehow that evolved into 70% of backend APIs running JS in places nobody expected a browser language to survive

what's in here

This full section follows the w3schools Node.js tutorial curriculum but with the 0x1RIS treatment - dry humor , security focus , and zero hand-holding. Every file builds on the last one so don't skip around unless you already know what you're doing

  • node_00 - HOME (this page)
  • node_01 - Intro - what Node actually is
  • node_02 - Get Started - install and run your first script
  • node_03 - JS Requirements - what JS you need to know before diving in
  • node_04 - Node vs Browser - same language , completely different capabilities
  • node_05 - Command Line - running Node files , flags , REPL
  • node_06 - V8 Engine - the C++ beast under the hood
  • node_07 - Architecture - how V8 , libuv , and bindings fit together
  • node_08 - Event Loop - the single most important concept in Node

Future sections will cover: modules , NPM , file system , HTTP , streams , Express , databases , authentication , testing , and production deployment

security angle

Node's attack surface is fundamentally different from browser JS
In a browser , JavaScript runs in a sandboxed environment with no filesystem access , no raw network sockets , and no process control. A DOM-based XSS can steal cookies but it can't read /etc/passwd. Node removes every one of those restrictions - the same fetch() that hits an API in the browser can now read your internal network. The same eval() that was dangerous in the browser is now a full RCE vector

// Browser JS - annoying but contained
// document.cookie is the worst that happens

// Node.js - this is production-destroying
const userInput = req.body.code
eval(userInput) // RCE with filesystem, network, process access

This section will hammer security from every angle because that's the whole point of this blog

attack surface overview

When you run Node in production , these are the things that will burn you if you don't understand them:

  • Event loop starvation - one CPU-heavy endpoint blocks all other requests
  • Module caching - secrets loaded at startup stay in memory for the process lifetime
  • global namespace - any dependency can read anything you put there
  • Prototype pollution - JSON parsing can inject properties into Object.prototype
  • Supply chain - every npm install pulls unknown code into your runtime
  • Unvalidated input - same problem as every other backend , but JS coercion makes it worse
  • No sandbox - vm module is not a security boundary , despite the name

Each of these gets its own deep dive in later files. For now just know Node is powerful and that power cuts both ways

prerequisites

none - just show up with a terminal and willingness to learn

how this section is organized

Each file builds on the one before it Start at node_00 and work forward. Every file ends with a "next ->" link pointing to the next file. Code examples assume you've read the previous concepts. You can jump around if you already know the basics , but don't complain when node_08_event_loop references V8 internals explained in node_06

The format stays consistent: explanation first , code example second , security angle third. If you're here for the security context , every file has a dedicated ## security section or ## common pitfalls. The tone stays dry and direct - no hand-holding , no motivational quotes , just working knowledge that translates to real servers

next -> node_01_intro.md