Mastering Cyber Security in This Crazy World!

1st Edition · RWID · Ecobook Edition

Written by Eko Suprapto Wibowo, founder of Remote Worker Indonesia.

This book grew out of one real event: an automated attack on remoteworker.id on 2 October 2026. Instead of hiding it, we opened it up and used the attack as teaching material. Every chapter follows the same pattern:

theory → the common industry approach → how Ecosphere does it → a fragment of the real incident.

This book is not a news summary. It explains why a system is built the way it is, not merely what was installed.

This book grows. Every new attack that hits RWID will become a new chapter in the next edition. Buying this book means owning a record that keeps growing — not something you read once and are done with. The more people try to bring us down, the thicker the book gets.

Foreword

RWID (Remote Worker Indonesia) has been running since 2017. In 2025 it went viral — and the virality came with sideways accusations from many people who did not know it: scam. I have told the human side of that story on the Welcome page of this app, and I will not repeat all of it here. The only consequence you need to know is this: RWID stopped, and a year later decided to return.

When I decided to return, I rearranged the priorities. Not features first. Not looks first. Security first. The reason is simple: that scam accusation, true or false, made me realize that RWID could never prove anything if its system collapsed the moment it was attacked. In 2025, I built fast, used many third-party services, and adapted in ways that I myself consider indefensible. One of them caused all of RWID’s stored procedures to disappear. Since then I have held to one principle: Zero Trust — trust nothing that comes from the internet until it proves itself.

So when RWID came back in 2026, I built it on a different foundation, and I openly challenged the world:

Public Challenge: Can you break this??! Spoiler alert: you can't!

That post — on Instagram and Threads — was the trigger. I deliberately opened myself up. The attack that came was no surprise; it was a guest we had invited. The goal was single: to prove, publicly, that this system is strong — and if it turned out not to be, we wanted to know now, not while millions of people were watching.

This book was born from that invitation. It explains the security theory behind it, the architecture we built, and the real attack that we actually fended off a few hours after that post spread.

One thing you will see again and again: our strength is not in one big wall, but in the way we compose the system so that one small fix can spread quickly to everything. That is Ecosphere.

— Eko

How to Read This Book

This book is written for product builders — especially those who learn while building (vibe coders, solo builders, beginners to intermediate). There is no assumption that you already understand security. What I do assume: you can build a web application, and you want to build it to production standards.

Each chapter follows the same pattern, and this pattern is what makes the book useful:

Theory. The basic concept, and the reasoning behind it. Not memorization.
The common industry approach. How the world usually handles it.
The Ecosphere way. How the platform we built applies it.
A fragment of the incident. A piece of the real attack of 2 October 2026 that illustrates the point.

You can read in order, or jump to the chapter you need. The → marker points to further reading. I keep English technical terms when they are the standard term (payload, rate limit, query), so that you recognize them in any documentation.

This book does not replace practice. At the end there is Tools: buttons to run attack simulations in the RWID portal, a security-setup checklist, and a report template for internet service providers (ISPs).

Part 1 · The Stage

1 · A Living World
2 · The Incident at a Glance: one IP, eighteen minutes
3 · What Is Ecosphere (and why LXS alone is not enough)

Part 2 · Why This System Is Strong

4 · Theory Roots: Domain-Driven Design & Bounded Context
5 · LXS: Linux Services as building blocks
6 · Gateway & Auth: the source of strength that fixes fast

Part 3 · Security Foundations

7 · Security Is a Property of the System, Not a Feature
8 · Threat Model & Attack Surface
9 · Deny-by-Default, Least Privilege, Defense-in-Depth

Part 4 · Attack Classes & Defenses

10 · Injection & Parameterized Queries
11 · XSS, Escaping, and Content Security Policy
12 · Sessions & Authentication: from localStorage to HttpOnly
13 · Secrets Management
14 · SSRF, Open Redirect, and URL Validation
15 · Abuse: Signup Spam, Bots, and Scanners
16 · The Software Supply Chain

Part 5 · Operations & Scale

17 · The Edge: WAF, DDoS, and Why the Origin Barely Notices
18 · Observability & Alerting: a Guard That Shouts
19 · Calm Incident Response
20 · Scale Readiness & Quotas

Part 6 · Case Study & Tools

21 · Case Study: The Full Timeline of 2 October 2026
22 · Ecosphere Security Architecture, End to End
23 · Tools: Test Your Own System

This book grows. Every new attack that hits RWID will become a new chapter in the next edition. Buying this book means owning a record that keeps being updated — not something you read once and are done with.

1 · A Living World

Before the incident, before the theory, there is one thing you need to see first. This is the face of RWID:

That globe is not decoration. It was not made casually. It is designed as a real-time global system monitor — a single screen that answers the question “what is happening across the whole RWID world?” without having to open a technical dashboard.

What it monitors

RWID HQ in Yogyakarta — the gold dot that marks its home.
Ecosphere HQ and its nodes — where the platform runs, including production nodes abroad. If a node is up or down, you see it here.
Every member — when someone signs in or registers, a pulse appears at their location, complete with name and city. This world moves because of its inhabitants.
A continuous heartbeat — the pulse and activity signals that make the “world” feel alive, not just a static map.

It is two things at once: social proof (visitors see that the community is real and active) and an operational monitor (where traffic comes from, which nodes are healthy). One screen, two functions.

This is what it looks like during an attack

The RWID globe while the attack was underway

That is a capture of the globe while the 2 October 2026 attack was underway. Strange names kept popping up from the very same point — Cikarang — back to back, fast, and unnatural: a line of entries without a pause from the same city, in a pattern no ordinary human could produce. The world that had been calm suddenly filled with a single source.

And because every pulse comes with a sound, I did not need to be looking at the screen to know something was wrong. The ears caught it before the eyes had time to read. As soon as that sound came in a rapid series, the reflex was one thing: open the globe, and there it was, already clear.

That is the real value of a monitor: not just displaying data, but making what is wrong visible and audible — impossible to miss.

The globe is not the only one that shouts. On the Telegram channel, our bot sends the same warning — automatically, from the guard that watches the edge:

Two signals arrived almost together: the eyes (the globe) and the machine (Telegram). That is no coincidence. The system is designed to notify from more than one direction — so that an event that slips past the eye is still caught elsewhere. Good detection does not depend on a single sense.

Why this matters for a security book

Because this is exactly where the oddity shows. When a system is monitored as one living world, what is abnormal stands out — a strange name, a pulse that is out of place. Not because someone is reading logs at three in the morning, but because the world itself shows that something is wrong.

A good monitor does not just display numbers; it makes what is wrong feel wrong. This globe is the plainest example of that principle, and the incident we discuss starting in Chapter 2 is the proof.

→ Chapter 2 · The Incident at a Glance.

2 · The Incident at a Glance: one IP, eighteen minutes

Before we get into theory, let us first look at what actually happened. This is the excerpt we have already published as an engineering note in the Ecosphere documentation, simplified for readers of this book.

On 2 October 2026, around 18:16–18:37 WIB, a single IP address in Cikarang, West Java, ran an automated vulnerability scanner against remoteworker.id. In that window, our edge (Cloudflare) blocked 397 requests. The scanner targeted the sign-in and sign-up endpoints (/signin, /signup, /api/auth/register), sent injection probes, and swept WordPress exploit paths that have been well known for decades.

What matters is not the numbers. What matters is what did not happen:

Not a single piece of data leaked.
The production server’s processor (CPU) stayed below normal load; the host barely blinked.
Not a single junk account could get in, because email verification is mandatory.
Our old server never even saw most of those requests, because they were all rejected at the edge.

The only trace that slipped through: 43 junk accounts that registered from that IP. We deleted all of them; the 30 genuine registrants remained intact.

First lesson: the attack that makes you stronger is not the one that fails, but the one that is detected, contained, and reported with evidence.

This incident was no surprise. It was the answer to the challenge we spread ourselves. The rest of this book explains why the system could stay that calm, and what you can copy for your own system.

→ Continue to Chapter 3 · What Is Ecosphere to understand the foundation that makes all of this possible.

3 · What Is Ecosphere (and why LXS alone is not enough)

Explaining “LXS” without explaining Ecosphere is like explaining bricks without explaining the building. So we start from the building.

The problem it wants to answer

The standard way of building applications in the 2020s stacks up layers: the application is wrapped in a container, the containers are orchestrated by Kubernetes, plus a service mesh, a message broker, and a long list of managed services. For a large team, that is reasonable. For one person building a product, it is a burden: every layer adds surface that can go wrong, and — more important for this book — surface that can be attacked.

Ecosphere takes another direction. It treats an application as a collection of small, complementary capabilities, not one giant monolith nor a countless swarm of containers.

The core terms

Domain. One clear, self-contained responsibility — identity, articles, wallet, notifications. Each domain has its own data and talks through contracts, not by importing each other’s code.
LXS (Linux Services). The way a domain is packaged into one ready-to-run binary with a firm contract: the variables it needs, its port, memory, and which routes it opens. Details in Chapter 5.
Estate. The set of LXS + core code (the domain core) that forms one complete application. remoteworker.id is an estate.
Registry. A versioned catalog of LXS. You reuse capabilities that are already tested instead of rewriting them.

Why this matters for security

One sentence: one capability in one place means one place to fix. If there is a weakness in the authentication LXS, you fix it once, publish a new version, and every estate that uses it can upgrade. You do not fix login code that was copied into ten projects.

That is what we call propagated strength: a fast fix at one point spreads across the whole system, instead of being left behind in a single application.

Try it yourself

Ecosphere is not theory locked inside this book. The platform is open to try — from installation, to documentation, to composing your first application:

→ https://getecosphere.com

The more people build on it, the more people help strengthen the same foundation. That is part of the intent: security that is shared, not maintained alone.

In the next chapter we dig into its two theoretical roots — Domain-Driven Design and the LXS concept itself — before moving on to the chapter that matters most for our strength: Gateway and Auth.

4 · Theory Roots: Domain-Driven Design & Bounded Context

Before there was LXS, there was the idea first: Domain-Driven Design (DDD). This book will not teach DDD in full, but there is one concept you need to understand, because our security rests on it.

Bounded context: one word, one meaning

Imagine the word “user”. In the identity domain, a user means an account with a password and a session. In the articles domain, a user is merely an author. In the wallet domain, a user is the owner of a balance. If you force a single definition of “user” on everything, your code slowly becomes mutually dependent, and every change touches everything.

Bounded context is the answer: set clear boundaries. Each context has its own model, its own data, and its own contract. They do not borrow data types from each other.

The binding rules (and why this is about security)

A system built on firm boundaries has properties that are valuable for security:

No imports between domains. A domain communicates with another domain through a public contract (usually HTTP), not by calling its internal functions. This means a domain’s attack surface is neatly closed: it can only be called through the declared door.
Separate storage. Each domain has its own database. A vulnerability in one domain does not automatically open the entire database. The blast radius is small.
References, not copies. A domain stores a reference to data owned by another domain (an ID), not a copy of it. There is no data duplicated and inconsistent across many places.
Explicit identity at the boundary. A write operation does not silently infer the owner from the token; it asks for explicit proof.

In short: clear boundaries are a security control. When a component can only be reached through one declared door, reasoning about its security is much easier than for code wired to everything else.

From concept to binary

DDD explains how to think about boundaries. It does not explain how to package those boundaries into something that can be run and composed safely. For that we need LXS — the subject of the next chapter.

→ Chapter 5 · LXS: Linux Services as building blocks.

5 · LXS: Linux Services as building blocks

LXS is the way a domain is packaged into one ready-to-run binary, complete with a contract that both machines and humans can read. It runs natively inside LXC — without a heavy virtualization layer, without piles of container images.

What a LXS contract contains

Every LXS declares itself openly:

The environment variables it needs (and which of them are secrets).
The port it occupies.
The resources (memory, disk) it requests.
The routes it opens — and at what access level (public, auth, role:...).
The network: where traffic comes in from, where it goes out to.

This contract is not passive documentation. At deploy time, the platform checks whether the estate really provides what is requested — and rejects a composition that does not match. A LXS cannot quietly access something it has not declared.

Versions that never change

LXS are published in immutable versions: [email protected] means exactly that binary. You do not alter a version that has been published; you fix things by publishing a new version. As a result, fixing a weakness becomes a firm and traceable action: one new version, one changelog entry, one decision to upgrade in the affected estates.

One domain, one binary

The rule “one LXS = one domain” keeps the binary small and focused. Its attack surface is small too: this process does not carry capabilities it does not need. No large interpreter, no all-purpose framework; only what is necessary.

Shared capabilities, not copies

This is the heart of the whole book: login, notifications, storage, articles — they are all the same capabilities in almost every application. We do not copy them into each project; we publish them once as a LXS, then reuse them repeatedly. When there is a security problem in one of them, the fix does not need to be repeated in ten places.

Two LXS decide our strength more than any others. Both are covered in the next chapter.

→ Chapter 6 · Gateway & Auth: the source of strength.

6 · Gateway & Auth: the source of strength that fixes fast

If this book has one chapter I most want you to remember, this is it.

In many systems, security is scattered: each service guards itself, copies the login logic, and has its own interpretation of who may come in. The result is predictable: inconsistent, hard to audit, and fixing one weakness means touching many places.

We do it the other way around. Two LXS hold almost all security decisions, and both sit in front of every estate.

Gateway: a front door that refuses by default

The gateway is the only entry point from the internet to an estate’s services. It works deny-by-default: a route can be passed only if the estate writes it explicitly, along with its access level (public, auth, role:superadmin). There is no “forward everything”. There are no shortcuts.

The consequences:

Internal services do not need to be (and must not be) exposed directly. Only the front door talks to the outside world.
Every request is checked once in one place. If there is a new rule or a weakness in the access logic, it is fixed in the gateway, and every estate gets it.
When learning from incidents like 2 October, we added rules at a single point — and the whole estate became safe at once.

Auth: one identity authority

Auth is the LXS that holds identity: passwords, sessions, tokens, roles. It can also act as an identity provider (OIDC) so that several applications can share one account. Because all estates use the same Auth, their session model is uniform too — and that matters, because most web attacks target sessions.

One of the most impactful decisions was moving the session from localStorage to an HttpOnly cookie. An HttpOnly cookie cannot be read by any script on the page, so a single XSS hole does not automatically mean session theft. This change, too, was made once in Auth, then applied in every estate that uses it. (The full story is in Chapter 12.)

Why this is “propagated strength”

Imagine three worlds:

The copy world. Login is copied across 10 applications. A session weakness is found. You fix 10 places. Some are missed. The ones that are missed stay fragile for months.
The monolith world. One fix reaches everything — but only in that application. Other applications keep their own problems.
The LXS world. Auth is fixed once, its version is bumped, and every estate that composes it can upgrade. One fix, wide reach, on record.

That is why I call gateway and auth our source of strength. Not because they are perfect, but because they let us move fast when imperfections are discovered — and that matters far more than an unprovable claim of “secure”.

A fragment of the incident

When the 2 October scanner fired at the entry routes, it was not each service that held the line. The gateway rejected the majority, and Auth made sure the registration firewall (email verification) stayed intact. We did not need to touch twenty components; one door and one authority were enough.

→ That is the conceptual foundation. Part 3 starts with the security principles that apply to any system, LXS or not.