What is cybersecurity?

Cybersecurity is the work of keeping digital systems trustworthy when people, software and networks do things you didn't expect.

That definition is broad on purpose. It can include bank fraud, malware, phishing, cloud infrastructure, network defense, privacy, incident response and a dozen other specialisms. This handbook isn't trying to cover all of that.

This handbook is about application security for developers: the security of the code you write, review and ship.

JunoWhat is cybersecurity? Cybersecurity is a big word, but this handbook keeps it close to the code. We care about the form field someone edits, the order record someone asks for, the token that proves who they are, and the route that gets called too many times.

That's enough to start. You don't have to learn every security job at once.

JunoWhat is cybersecurity? Cybersecurity covers a lot of ground. The useful slice here is application security: the places where a request, a user, a database record or a token meets code you ship.

That keeps the work concrete. If you can reproduce the bug by changing a route, body, cookie, token, schema or middleware path, it belongs in this handbook.

JunoWhat is cybersecurity? The boundary here is deliberate: application security, not the whole security industry. The test is whether the failure comes from code, configuration or data flow a developer can reason about, change and regression-test.

That still leaves plenty to break: injection, identity, authorization, availability, secrets and logs. Malware, network defense and compliance can keep their own books. This one has enough sharp edges already.

That means we care about questions like these:

• What happens if a user changes a hidden form field before sending it?
• Can one customer read another customer's order?
• What happens if a login token leaks?
• Can one route be called thousands of times until the app slows down?
• Does the server check the data, or does it only trust the browser?

Why these questions?

They sit inside the codebase, the API, the database query, the session cookie and the validation schema. That is the developer-sized part of cybersecurity this handbook teaches.

How we got here

The word is newer than the problem. Computers started as shared machines in labs, then moved into offices, homes, phones and payment systems. Once software began carrying money, identity and private records, breaking the software stopped being a prank and became a way to steal, spy, disrupt or impersonate.

The web sharpened that shift. A browser is a friendly front door, but it sends text your server has to interpret: URLs, headers, cookies, forms, JSON bodies, file uploads.

Every request is a little story the browser tells your server, and the server has to decide how much of it to believe.

Why developers need it

Early websites were mostly documents. You visited a page, read it, clicked a link and moved on. Modern web apps are different. They take payments, store personal data, manage identity, call APIs, upload files and make decisions on behalf of users.

A normal feature can become a security bug when it trusts the wrong thing. A search box can become an injection point. A profile page can leak someone else's data. A useful export button can become a denial-of-service problem if one request asks the database for too much work.

The good news is that most of this is learnable. You don't need to become a cryptographer or a network engineer to write safer backend code. You need a few habits:

• Notice where input enters the system.
• Check decisions on the server.
• Treat identity and permissions as separate questions.
• Think about what could go wrong before the feature ships.
• Know the common bug classes well enough to recognise them.

That is the path this handbook follows.

JunoWhy developers need it A security bug is often a normal feature trusting the wrong thing. The browser says this order belongs to me. The URL says this is my record. The request says this price is three dollars.

The server has to ask, "Do I know that myself?" That one question carries a lot of the course.

JunoWhy developers need it Modern apps are security boundaries because they make decisions: who can see a record, which action is allowed, whether input is valid, and how much work one request may ask for.

Rule of thumb: find the decision, then find the data it used. If the data came from the browser, a token, another service or an old database row, make the server prove it before trusting it.

JunoWhy developers need it Most app security bugs are ordinary control-flow bugs with a hostile caller in the room. The branch ran, the query returned, the middleware passed, and the invariant still failed because the deciding value came from the wrong side of the boundary.

The production version is dull and useful: put the control where the invariant is enforced, test the bad path, and leave evidence for the next person who wonders why the check exists.

The path from here

The path starts with a simple idea: secure code begins with how we think.

That is why the first section starts with STRIDE and OWASP. STRIDE helps you ask what could go wrong while an app is still being designed. OWASP gives you names for the bugs that show up once real apps are running in the world.

First we build the mindset, then we move into the concrete developer work: unsafe input, XSS, SQL injection, validation, authentication, tokens, OAuth, rate limiting and throttling.

JunoThe path from here The first few chapters are about learning the questions. What could go wrong? Who is this request from? What is this user allowed to touch? What happens if the input is hostile?

After that, the chapters turn those questions into code.

JunoThe path from here The order matters. STRIDE gives you design-time questions, OWASP gives you names for live bugs, then triage turns a finding into impact, priority and next action.

After that, the track applies the same loop to input, identity and traffic. The fix is easier to remember when it stays attached to the bug it prevents.

JunoThe path from here The path is a working loop: predict failures before the build, recognise the ones that ship, decide which ones matter first, then feed the lesson back into the next design.

The later chapters are concrete instances of that loop: interpreters, identity systems, permissions, request volume and operational evidence. Same coffee, new failure mode.

## What this handbook is not

This isn't a full cybersecurity survey. We are not covering malware analysis, penetration-testing tooling, network defense, compliance frameworks or security operations.

Those topics matter. They sit outside the job this handbook is doing.

The job here is narrower and more practical: help you build backend applications that are harder to misuse, easier to reason about and safer to put in front of real users.

JunoWhat this handbook is not Leaving topics out is part of making the handbook useful. We are staying with the code you can open, read and change.

That means routes, schemas, cookies, tokens, queries and middleware. Plenty to learn, without pretending one handbook can teach every security field.

JunoWhat this handbook is not The scope is application security for backend developers. That keeps every chapter close to a route, schema, cookie, token, query, middleware function or deployment setting you can inspect.

When a topic needs a SOC, a packet capture, a compliance programme or a malware lab, it is outside this track. Useful, but not the job this handbook is doing.

JunoWhat this handbook is not The narrower scope is what gives the handbook teeth. A broad survey would name every security field and teach none of them well, which is how you get a checklist nobody owns.

This track follows the systems a backend developer can change, review and test: request handling, identity, authorization, validation, throttling, storage and operational hygiene.

Where this goes next

The word is narrowed: application security, the code you write, review and ship. The scope is set, and the questions worth asking are on the table.

What's missing is the habit of asking them. How to think about security is where that starts, with trust boundaries and the reflex of looking at your own code the way somebody unfriendly would.