Secure Coding in Spring Boot and Express Through Real-World Hacking Incidents

The site you manage is under attack right now, too

[Related reading]

- Velog series “Hacking Methods vs. Defense Methods”: https://velog.io/@bumicklee/series/defense

Servers exposed to the internet receive requests from automated scanners and bots every day. Leaked passwords are continuously tried on login pages, while someone changes order numbers one by one to view other people’s orders.

The problem isn't whether attacks are coming. They're happening right now. The real question is: what are the three things we need to know?

1. Does that request work? If it returned 200, you’ve already been breached.

2. Can you detect it? At 3 a.m., no one is watching the logs.

3. Can you prove it was blocked? "We fixed it"—with test results, not just words.

This course answers three questions with code.

How to Survive the Era of AI-Powered Hacking Automation

In October 2026, the Seoul Metropolitan Police Agency announced a series of breaches in which hackers using AI stole approximately 8.2 million records from around 90 organizations (figures may change as the investigation is ongoing).

AI hasn’t performed any new magic. It just helps hackers quickly find weak spots they couldn’t find before. Automated attacks have patterns, and they target the same places as before. If you know those patterns and block them in advance, there will be fewer weak spots for AI to find, no matter how quickly it searches.

When you read about a hacking incident in the news, where would it have happened in our code?

SK Telecom SIM information leak, Coupang data breach affecting 33.67 million people, TVING access key exposure, Lotte Card hack, GS Retail credential stuffing, Binance’s $6.4 billion.

We hear about security incidents every week. But no matter how many articles you read, you still won't find an answer to the question "So what should I fix in my own code?".

This course answers that question with code. You’ll run a real open-source shopping mall on your PC and reproduce firsthand where each of the 22 incidents occurs in the code. Then you’ll block them one by one and verify with tests that they’re blocked.

Even famous open-source projects aren’t safe

This course uses real open-source online stores with tens of thousands of GitHub stars, not toy examples. They are the Spring Boot store mall (over 80,000 stars) and the Express store EverShop (over 10,000 stars).

But when we first audited this well-known codebase, we found 74 issues: 48 in the Spring Boot project and 26 in the Express project. Some of them were critical vulnerabilities like these.

• Changing the order number is all it takes to access someone else’s order.

• Any logged-in user can directly mark a payment as “Complete.”

• The SMS verification code is included in the API response.

• Tokens without signatures are accepted.

The moment you use open source, its flaws enter your service too. In this course, you’ll follow this checklist to fix Spring Boot and Express code one issue at a time and build your defensive skills. The ability to spot problems in code written by others is what helps protect your own company’s code. (The checklist includes flaws identified in the original code, default demo settings, and operational configuration mistakes added for the exercises.)

Covers both Spring Boot and Express

• Spring Boot (main course): In 96 lessons across 15 sections, you’ll reenact, fix, test, and inspect detection logs—all hands-on.

• Express: In every main course lesson, we show the corresponding fix diff for Express, and you’ll directly block the same attacks in 18 Express mini-practices that run on Node.js alone, without Docker. In Section 16, follow along with the video from installation through a complete round of hands-on practice.

• Even if your team uses both stacks, there’s no need to worry. The principles for blocking attacks are the same, and we use the same test to verify that they’re blocked.

Bonus Lessons for Express Developers: Section 16

For those using Express, we’ve created a separate Section 16, “Getting Started with Express Hands-On Practice” (6 lessons). No Docker or database server required. All you need is Node.js 24.

After completing Section 16, you’ll work through 18 Express mini-exercises. Using the same lesson numbers as the main course, you’ll use Express code to directly prevent people from viewing others’ orders, accessing exposed admin URLs, mass assignment, SSRF, SQL injection, XSS, password guessing, token lifetime issues, default secret values, error response leaks, audit log issues, log exposure, and simultaneous coupon use. Commands and actual results are included in the “Express Follow-Along PDF,” and the underlying principles and before-and-after diagrams are covered in the “Express Beginner Edition Course Textbook PDF.”

The Express course videos will continue to grow even after release. We plan to add Section 17, “Trying It Out with Express” (13 videos) and Section 18, “Additional Resources for Express Users” (4 videos: middleware order, asynchronous errors, cookies and sessions, and npm dependencies) as updates. The videos were recorded and tested on macOS.

Hacking is no longer news—it’s a developer’s job

• When an incident occurs, the first person called in is the developer who wrote the code. The difference between developers who have experience preventing incidents and those who don’t becomes clear on the day one happens.

• The faster AI writes code, the more valuable a developer’s ability to assess and prove that code is secure becomes. This course gives you hands-on practice developing that skill.

Do any of these concerns sound familiar?

• "I know I need to study security, but I don't know where to start." → In Section 1, use an incident map and threat modeling to decide what to look at first in your service.

• "I've read the OWASP Top 10, but I don't know what those vulnerabilities look like in our code." → This isn't a toy example. You’ll work on the 「Daon Market」 code as if it were company code, forking mall, a Spring Boot shopping mall with over 80,000 GitHub stars.

• "I fixed it, but I’m not sure it’s really blocked." → The same attack replay changes from [red] to [green], and the course test and scoreboard confirm it with numbers.

• "I don’t know what to do if an incident occurs. We don’t even have a security team." → You’ll get hands-on practice with detection rules, alert response runbooks, first-hour procedures, and deciding whether to report a personal data breach.

What you’ll have when you finish this course

By following the course all the way through, you’ll finish with more than knowledge you simply listen to—you’ll have deliverables you can put to work in your company’s services right away.

1. Final source code for an online store with all 37 vulnerabilities fixed

At the start, the scoreboard reads “37 vulnerabilities.” The number drops as you work through each section, reaching zero in the final lesson. Use the finished source code, with all vulnerabilities fixed, as a baseline for your own service. It becomes a reference you can turn to whenever you get stuck: where to put ownership checks, how to read secrets, and how to handle payment callbacks idempotently.

2. Defensive Components for Company Services: secure-kit

We organized the defensive code we fixed by hand in class into modules for each type of threat. In Spring Boot, add them as starter dependencies and configuration; in Express, add them as middleware. Just enable the modules you need.

3. Detection rules to catch data leaks early

Alongside the code that blocks attacks, logs of attack indicatorsare also put in place. We log signals such as attempts to view someone else’s orders, bulk queries, and requests to internal addresses, then turn them into Grafana dashboards and alert rules. It took several months to discover the Coupang breach. In this course, you’ll learn how to reduce the time it takes to detect an incident.

4. Evidence to Support Proposing Architectural Changes

We don’t just fix the code. Starting from the initial state (A0), which had only an app and a database, we add a gateway, network segmentation, an egress proxy, a secrets store (OpenBao), log alerts (Loki·Grafana), and immutable backups (MinIO), one by one, building it up to A11. This gives you concrete justification to use as-is when writing a proposal at your company to “change the architecture this way.”

5. Documents to Pull Out When an Incident Occurs

• When an alarm goes off, follow these six runbooks from top to bottom (the first hour of an incident, mass queries, ownership denial, audit log integrity, partner bulk export, and alert response)

• 7 templates (attack surface map, initial assessment report, 30-minute incident summary, breach reporting decision, breach notification, capstone timeline, retrospective)

• An online checklist to assess your service with 60 questions

6. How to Analyze Incidents

By the end of the course, when a new incident makes the news, you’ll be able to figure out within 30 minutes "where we would have stopped it if it had happened to our service". That’s because you’ll repeatedly examine 22 incidents using the same framework: What failed → Where in our code could it happen → How can we prevent it → How can we detect it?

What stays with you throughout your career: from a developer who only builds features to one who protects services

• Portfolio: The code you fixed, your initial assessment report, and your incident analysis remain as a record of your work.

• Interview answer: You can answer the question "How do you prevent security incidents?" with a real incident and your own code.

• Next steps: Threat modeling, architectural recommendations, and incident response are skills expected of senior engineers and leads. This course gives you practice in all three.

Why You Should Take This Course: It’s Time to Level Up

There are three reasons you should take this course.

1. Attacks are already automated. Bots and AI never stop looking for weak spots. Those who recognize the patterns and shore them up first are the ones who survive.

2. When an incident occurs, you’re the first one called in. The developer who wrote the code has to explain what went wrong and fix it.

3. The ability to keep systems secure is valuable. In an age when AI writes code, developers who can assess and prove that it’s safe are in high demand.

Each lesson follows five steps

All hands-on lessons follow the same sequence, so after following just a few, the flow becomes second nature.

1. The incident and its underlying principles: We examine what failed through a real incident.

2. Reproduction (Red): Use make replay to confirm that the same attack works on our online store. [Red] Vulnerable appears on the screen.

3. Fix: Modify the Spring Boot code directly. The places to fix are marked in the code.

4. Verify (green): Check that the same replay now shows [Green] Blocked and that all course tests pass. Also confirm that normal users can still use the app as before.

5. Detection: Place a security event log where the issue was blocked, then rerun the reproduction to check whether the log is recorded.

22 real-world incidents covered

Based on official investigation findings and media reports, we point out “here’s where it is in our source code” for each incident.

• South Korea: SK Telecom SIM data leak, Coupang personal information leak and signing key, TVING access key exposure, Lotte Card hack, GS Retail credential stuffing, KT micropayments and femtocells, Yes24 and SGI Seoul Guarantee ransomware attacks, Upbit hack

• International: MOVEit SQL injection, Snowflake customer account takeover, Microsoft Storm-0558 signing key, M&S and Change Healthcare help desk attacks, Salesloft Drift integration token, Binance and Bybit signing incidents, Capita, Jaguar Land Rover, Cloudflare and AWS outages, etc.

It includes all ten items in the OWASP Top 10:2025, plus 20 risks that aren’t on the list but frequently occur in practice (request smuggling, someone else’s page left in the cache, concurrent coupon use, retry storms, card testing, and more).

We change the architecture too: from A0 to A11

Daon Market is a real-world shopping mall setup consisting of a customer app, an admin app, MySQL, MongoDB, Redis, RabbitMQ, and MinIO. It all runs on a single PC using Docker Compose. With each section, you’ll add another layer of defense to this setup and see on the map exactly what has changed. No cloud account required.

We made it very easy to follow along

The most common reason people give up on security training courses is "I can’t get the environment set up." That’s why we’ve put a lot of effort into making them easy to follow.

• At the starting point of any lesson: One line, make goto L=8-3, updates the code and data to the starting state of 8-3 with the answers from previous lessons applied. You can skip the previous lessons.

• Tells you what command to type next: even if you come back after a few days off, make where shows your current position, and make next shows the next command.

• When things don’t work, start with a diagnosis: make doctor checks Docker, memory, disk, settings, and containers, and gives you fixes one line at a time.

• If you get stuck, compare your work with the solution: make solution shows the lines that differ between your code and the solution.