Web Engineering: arkitektura, seguridad at gawi ng team

01

Arkitekturang kaya mong ipaliwanag at ipagtanggol

In simple words

Ang bahay ay may mga kuwartong magkakaiba ang trabaho: kusina, tulugan, bodega. May mga pintong naka-lock, at ang harapang pinto ang pasukan ng mga estranghero. Kayang ituro ng magaling na arkitekto ang plano at sabihin kung para saan ang bawat kuwarto at kung nasaan ang bawat kandado. Ang magandang app ay may ganitong plano rin.

Bago ang course na ito: Full-Stack Basics: servers, databases and deployment (course 7.7.3). Dapat nabuo at na-deploy mo na ang "Study Notes": isang Node.js JSON API na may mga input check at limitasyon sa laki ng body, isang SQLite database na may prepared statement, scrypt password hashing, mga session cookie na may HttpOnly at SameSite, mga ownership check sa bawat note, 9 na automated test, at mga setting sa environment variable. Ngayon, hindi ka na lang ang nag-iisang developer. Sa course na ito, magdidisenyo, magse-secure, magte-test at magpapatakbo ka ng app gaya ng ginagawa ng propesyonal na team, at matututunan mong ituro ang mga gawing iyon sa iba.

Key facts

Pinapanatili ng mga layer ang bawat bahagi ng code sa iisang trabaho:
Ang HTTP layer (mga route) ay nagbabasa ng mga request at nagsusulat ng mga response: mga status code, header, JSON.
Ang service layer ang may hawak ng mga patakaran: ano ang valid na note, sino ang maaaring magbura nito.
Ang data layer (isang repository) ay nakikipag-usap sa database at wala nang iba.
Ipasa ang mga dependency sa halip na likhain ang mga ito sa loob. Sa course 7.7.3, hinayaan ng createApp({ db }) ang mga test na gumamit ng in-memory database. Ang parehong ideya sa service layer ay nagpapahintulot sa mga test na gumamit ng pekeng repository, kaya masusubukan ang mga patakaran sa loob ng millisecond nang walang database.
Ang architecture decision record (ADR) ay maikling tala na itinatago ng team para sa bawat mahalagang pagpili: ang konteksto, ang desisyon at ang mga kahihinatnan nito. Makikita ng mga bagong tao kung bakit ganito ang itsura ng code.
Ang trust boundary ay lugar kung saan gumagalaw ang data sa pagitan ng mga bahaging magkakaiba ang tiwala mo: browser papunta sa server, server papunta sa database, server mo papunta sa API ng ibang kumpanya. Kailangan ng mga check ang bawat boundary.
Kasama sa OWASP Top 10 (2025) ang A06 Insecure Design. Sabi ng OWASP, magkaiba ang ugat at lunas ng mga depekto sa disenyo at mga bug sa coding, at na "hindi maaayos ng perpektong implementasyon ang insecure na disenyo".
Ang Threat modeling (OWASP Threat Modeling Cheat Sheet) ay nagtatanong ng apat na tanong: "Ano ang ginagawa natin?", "Ano ang maaaring magkamali?", "Ano ang gagawin natin tungkol dito?" at "Sapat ba ang ginawa natin?"
Ang STRIDE ay checklist ng anim na uri ng banta, na bawat isa ay sumisira sa isang katangian ng seguridad:

Banta	Sinisira	Halimbawa sa Study Notes	Depensa natin
Spoofing	Authentication	May nagla-log in bilang ibang user	Mabagal na may salt na mga hash, login throttle (Lesson 4)
Tampering	Integrity	Binabago ng isang request ang note ng iba	Ownership check sa service layer
Repudiation	Accounting	"Hindi ko binura ang note na iyon"	Security log kung sino ang gumawa ng ano (Lesson 7)
Information disclosure	Confidentiality	Tumatagas ang mga note o error sa maling tao	404 para sa mga note ng iba, pangkalahatang mga error
Denial of service	Availability	Napakalalaking request o walang katapusang pagsubok sa login	Limitasyon sa laki ng body, throttling
Elevation of privilege	Authorization	Naaabot ng karaniwang user ang mga admin na aksyon	Deny by default, mga check sa server

Ipinapakita ng data flow diagram ang mga proseso, data store, panlabas na entity, data flow at trust boundary. Sabi ng OWASP, pinakamahusay na gawin ang threat modeling nang maaga, sa panahon ng disenyo, at panatilihing napapanahon habang nagbabago ang system.

Halimbawa (service layer na may pekeng repository, nasubukan)

// Service layer: business rules only. No HTTP, no SQL.
// The repository (data layer) is passed in, so tests can use a fake one.
function createNotesService({ repo }) {
 function cleanText(text) {
  if (typeof text !== "string") return null;
  const t = text.trim();
  if (t.length < 1 || t.length > 2000) return null;
  return t;
 }
 return {
  list(userId) {
   return repo.findByOwner(userId);
  },
  create(userId, text) {
   const t = cleanText(text);
   if (!t) return { ok: false, error: "Note must be 1 to 2000 characters." };
   return { ok: true, note: repo.insert(userId, t) };
  },
  remove(userId, noteId) {
   // Ownership is checked here, once, for every caller.
   return repo.deleteOwned(userId, noteId) === 1;
  },
 };
}

// A tiny in-memory repository with the same methods as the SQL one.
function memoryRepo() {
 const rows = []; let nextId = 1;
 return {
  findByOwner: (u) => rows.filter((r) => r.userId === u),
  insert(u, text) { const r = { id: nextId++, userId: u, text }; rows.push(r); return r; },
  deleteOwned(u, id) {
   const i = rows.findIndex((r) => r.id === id && r.userId === u);
   if (i === -1) return 0;
   rows.splice(i, 1); return 1;
  },
 };
}

module.exports = { createNotesService, memoryRepo };

const test = require("node:test");
const assert = require("node:assert");
const { createNotesService, memoryRepo } = require("../src/notes-service");

test("creates a note for its owner", () => {
 const s = createNotesService({ repo: memoryRepo() });
 const r = s.create(1, " buy milk ");
 assert.strictEqual(r.ok, true);
 assert.strictEqual(r.note.text, "buy milk");
 assert.strictEqual(s.list(1).length, 1);
});

test("rejects empty and huge notes", () => {
 const s = createNotesService({ repo: memoryRepo() });
 assert.strictEqual(s.create(1, "  ").ok, false);
 assert.strictEqual(s.create(1, "x".repeat(2001)).ok, false);
 assert.strictEqual(s.create(1, 42).ok, false);
});

test("a user cannot delete someone else's note", () => {
 const s = createNotesService({ repo: memoryRepo() });
 const n = s.create(1, "mine").note;
 assert.strictEqual(s.remove(2, n.id), false);
 assert.strictEqual(s.list(1).length, 1);
 assert.strictEqual(s.remove(1, n.id), true);
 assert.strictEqual(s.list(1).length, 0);
});

Resulta ng test: pumasa ang lahat ng 3 test. Ang HTTP layer mula sa course 7.7.3 ay tumatawag na lang ngayon sa service.remove(user.id, id) at ginagawang 404 ang false. Nasa iisang lugar ang patakaran sa ownership.

Step by step

Iguhit ang Study Notes bilang mga kahon: Browser, Node.js server, SQLite file. Magdagdag ng mga palaso para sa bawat data flow (sign-up, login, paglista ng mga note, pagbura ng note).
Gumuhit ng putol-putol na linya sa bawat trust boundary. Check: may kahit isa sa pagitan ng browser at server, at isa sa pagitan ng server at database.
Gumawa ng src/notes-service.js at test/notes-service.test.js mula sa halimbawa, tapos patakbuhin ang node --test. Dapat makita mo ang 3 pumasang test.
Kasama ang isa o dalawang kaklase, itanong nang malakas ang apat na tanong ng threat modeling, isa-isa.
Punan ang STRIDE table para sa sarili mong app: isang totoong halimbawa at isang depensa para sa bawat titik.
Sumulat ng isang ADR (kalahating pahina): "Pinananatili namin ang mga ownership check sa service layer", na may konteksto, desisyon at mga kahihinatnan.
Check: kayang basahin ng bagong tao ang diagram at ADR mo at ipaliwanag kung nasaan ang patakaran sa ownership, nang hindi binubuksan ang code.

Watch on YouTube

Quick threat modeling of a simple web app with STRIDENetSec · YouTube · youtube.com

Videos by other creators on YouTube, for reference. They are not made by or affiliated with The Future Market.

LESSON 01Arkitekturang kaya mong ipaliwanag at ipagtanggol

LESSON 01 / ANIMATED LESSON / ENGLISH VOICE00:00 / 01:15

Voice

Read the video script

[Host] "Kayang ituro ng magaling na arkitekto ang plano at sabihin kung para saan ang bawat kuwarto. Kaya mo ba iyon para sa app mo?"
[Screen: tatlong kahon na may label na HTTP layer, Service layer, Data layer] "HTTP ang usapan ng mga route. Ang service ang may hawak ng mga patakaran. Ang repository ang nakikipag-usap sa database. Isang trabaho bawat isa."
[Screen: putol-putol na trust boundary sa pagitan ng browser at server] "Iguhit ang mga trust boundary. Bawat linyang tinatawiran ng data ay nangangailangan ng check."
[Text on screen: Ano ang ginagawa natin? Ano ang maaaring magkamali? Ano ang gagawin natin? Sapat ba ang ginawa natin?] "Tapos itanong ang apat na tanong ng threat modeling, nang maaga, kasama ang team mo."
[Text on screen: Hindi maaayos ng perpektong implementasyon ang insecure na disenyo] "Dahil hindi kayang iligtas ng perpektong code ang sirang disenyo."

Try it now

Magsagawa ng 30-minutong sesyon ng threat modeling sa sarili mong app kasama ang kahit isa pang tao. Gumawa ng data flow diagram na may mga trust boundary, STRIDE table na may anim na row at tatlong bagong gawain para sa backlog mo.

ClaudeStuck? Copy a ready-made prompt for Claude

Copy this, open Claude, paste it, and Claude will walk you through the lesson step by step.

For a grown-up: Claude is for adults (18+). Copy this, paste it into Claude, and use the answer to explain the lesson to your child.

I'm learning "Web Engineering: arkitektura, seguridad at gawi ng team" on The Future Market. Lesson 1: "Arkitekturang kaya mong ipaliwanag at ipagtanggol".

What the lesson teaches:
- Pinapanatili ng mga layer ang bawat bahagi ng code sa iisang trabaho:
- Ang HTTP layer (mga route) ay nagbabasa ng mga request at nagsusulat ng mga response: mga status code, header, JSON.
- Ang service layer ang may hawak ng mga patakaran: ano ang valid na note, sino ang maaaring magbura nito.
- Ang data layer (isang repository) ay nakikipag-usap sa database at wala nang iba.
- Ipasa ang mga dependency sa halip na likhain ang mga ito sa loob. Sa course 7.7.3, hinayaan ng createApp({ db }) ang mga test na gumamit ng in-memory database. Ang parehong ideya sa service layer ay nagpapahintulot sa mga test na gumamit ng pekeng repository, kaya masusubukan ang mga patakaran sa loob ng millisecond nang walang database.
- Ang architecture decision record (ADR) ay maikling tala na itinatago ng team para sa bawat mahalagang pagpili: ang konteksto, ang desisyon at ang mga kahihinatnan nito. Makikita ng mga bagong tao kung bakit ganito ang itsura ng code.
- Ang trust boundary ay lugar kung saan gumagalaw ang data sa pagitan ng mga bahaging magkakaiba ang tiwala mo: browser papunta sa server, server papunta sa database, server mo papunta sa API ng ibang kumpanya. Kailangan ng mga check ang bawat boundary.

The exercise I'm working on:
Magsagawa ng 30-minutong sesyon ng threat modeling sa sarili mong app kasama ang kahit isa pang tao. Gumawa ng data flow diagram na may mga trust boundary, STRIDE table na may anim na row at tatlong bagong gawain para sa backlog mo.

I'm stuck. Please:
1. Explain the main idea in plain, simple words with one everyday example.
2. Walk me through the exercise one small step at a time. Ask me what I've done so far before giving the next step.
3. Don't just give me the final answer. Help me do it myself, and check my work when I share it.

I'm a parent helping my child (about 8 years old) with a lesson called "Arkitekturang kaya mong ipaliwanag at ipagtanggol" from the course "Web Engineering: arkitektura, seguridad at gawi ng team".

Here's what the lesson says:
Ang bahay ay may mga kuwartong magkakaiba ang trabaho: kusina, tulugan, bodega. May mga pintong naka-lock, at ang harapang pinto ang pasukan ng mga estranghero. Kayang ituro ng magaling na arkitekto ang plano at sabihin kung para saan ang bawat kuwarto at kung nasaan ang bawat kandado. Ang magandang app ay may ganitong plano rin.

The activity:
Magsagawa ng 30-minutong sesyon ng threat modeling sa sarili mong app kasama ang kahit isa pang tao. Gumawa ng data flow diagram na may mga trust boundary, STRIDE table na may anim na row at tatlong bagong gawain para sa backlog mo.

Please explain this so an 8-year-old understands: short sentences, a fun everyday example, and no hard words.
Then give me 3 simple questions I can ask my child to check they understood, and a way to do the activity together, one tiny step at a time.

Open Claude

Sources

OWASP Cheat Sheet Series, Threat Modeling: cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.htm
OWASP Top 10 (2025), A06 Insecure Design: top10.owasp.org/2025/A06_2025-Insecure_Design/
Node.js documentation, test runner: nodejs.org/docs/latest-v22.x/api/test.html

My notes

I learned this

02