With identity verified (07-01) and the channel encrypted (07-02), an attacker can no longer read Ana's token or pose as Orders. But they can still be a legitimate user sending a malicious request: an id with odd characters, a 50 MB JSON, a MongoDB filter disguised as a string, or simply GET /v1/orders/ord-88214 to see whether it slips through. This lesson is about what each service does with what it receives and with what it stores: the principles that organize everything else, the OWASP API Security Top 10 walked through with TechCorp examples, input validation and sanitization with zod, injections (SQL, NoSQL, commands, logs), headers with helmet, dependencies, secrets in code, protection of personal data (GDPR at a practical level), auditing, security testing and vulnerability response. It ends with the checklist that gets added to the techcorp/node-service-template template. Authentication (07-01), TLS (07-02) and containers/Kubernetes (07-04) are only linked to.

Notice. The measures in this lesson are the usual ones for a development team, not a complete security program. The actual application of the GDPR, of PCI DSS and of any retention or audit policy must be reviewed with a security professional and with the organization's compliance/data protection officer.

1. Principles that organize the rest
2. OWASP API Security Top 10 (2023) with TechCorp examples
3. Input validation and sanitization with zod
4. Injection: SQL, NoSQL, commands and logs
5. Security headers with helmet
6. Dependency management
7. Secrets in code: never, and how to make sure
8. Protecting personal data: GDPR in practice
9. Auditing sensitive actions
10. Security testing: SAST, DAST, review and pentest
11. Vulnerability response
12. Per-service security checklist

Six principles that recur in every decision of this module:

The OWASP API Security Top 10 is the reference list of API risks. Walking through it with your own cases is the best way to internalize it:

Most of the remedies already exist in TechCorp's code; this lesson gathers them and adds the missing ones.

Rule: everything that comes in over the network is validated against a schema before touching it, whether it comes from the user, from another service or from an event. In 04-02 and 04-04 this is already done with zod; here it is hardened:

And in the routes, the route parameters too, which many forget:

And in app.js the global limits the template already shipped with, now justified: express.json({ limit: '100kb', strict: true }) (a larger body → 413; strict rejects JSON that is not an object or array), and at the gateway proxy-body-size: 2m on the Ingress (05-02) as the absolute ceiling. Sanitization versus validation: TechCorp prefers to reject (400) rather than silently "clean up"; the only accepted normalization is trim() and uppercasing codes (country.toUpperCase()), and always in the schema, never scattered around.

Injection happens when user data is interpreted as code or structure. Four variants that affect TechCorp:

SQL (PostgreSQL with pg). Never concatenate; always positional parameters, as OrderRepository already does in 04-04:

NoSQL (MongoDB in Catalog). The risk is different: not text, but objects. If a route does collection.find({ sku: req.query.sku }) and the client sends ?sku[$ne]=x, Express (with qs) builds { sku: { $ne: 'x' } } and the query returns every product; with $where or $regex it can be worse. Rule: never pass user objects into the filter; validate with zod that each value is a string (or number) and build the filter in the repository with fixed keys:

Also, express.json does not interpret operators, but a body { "filter": { "$where": "..." } } would indeed arrive as an object: same remedy (.strict() schema, no free-form filter).

System commands. They are almost never needed in a service; if they exist (generating a PDF, converting an image), execFile('convert', [path]) with arguments in an array, never exec(\convert ${name}`)`, and the file name validated with a pattern. Better still: a native library.

Logs. Log injection: a user puts the text "Gran Vía 12\n{\"level\":\"info\",\"message\":\"order paid\"}" in street and, if the log were plain text, a fake line would appear. With pino (06-01) the value goes serialized inside a JSON (newlines are escaped as \n), so the structure does not break; the rule is not to build messages by concatenating user input (log.info(\order from ${name}`)) but to pass it as a field (log.info({ customerId }, 'order created')`), and to remember that personal data never goes into the log under any circumstances (section 8).

helmet is a set of Express middlewares that sets defensive HTTP headers. At the gateway (what the browser sees) and in each service (defense in depth; and some, like the BFF, serve HTML):

helmet does not replace CORS (03-04): CORS says from which origin the browser may call; helmet says how the browser must treat the response.

A typical orders-service drags along 300 transitive packages; most real vulnerabilities come in through there. TechCorp's policy:

And npm audit in CI is not infallible: review the advisory, do not silence it with --force; if there is no patch, assess the risk (is the vulnerable function used?) and document the exception with a review date.

The rule has existed since 04-03 (secrets arrive through the environment or _FILE files, never in the repository or the image); here it becomes verifiable:

And locally, a pre-commit hook with gitleaks protect --staged. If a secret reaches the repository, the only correct response is to rotate it (git history is public forever to anyone who has cloned it): the mechanics of rotation — Secrets, External Secrets, restarts — belong to 07-04. Add .env, *.pem, *.key to the template's .gitignore; and remember that a secret in a console.log, in an error trace or in a request URL (?token=) is also a leak: hence redact (06-01) and configForLog() (04-03).

TechCorp processes Ana's personal data (name, email, address) and payment data. Without pretending to replace the data protection officer, the technical decisions a team must make:

• Minimization. Should order.created carry customer.email and name (02-02)? They are needed so that Notifications can send the email without calling Customers (autonomy, 03-02). Alternatives: (a) the event carries the data and all consumers receive it (Inventory does not need it); (b) the event carries only customerId and Notifications queries GET /v1/customers/{id} with its service token. TechCorp's decision: (a) for autonomy and because Notifications is the only subscriber that uses it today, under three conditions: personal data goes only in order.created (not in the rest of the saga's events), RabbitMQ is encrypted (07-02) and the queues and the DLQ have limited retention (messages in .dlq older than 7 days are purged after review: they are not an archive); and it will be revisited toward (b) if a second consumer appears that does not need it.
• Pseudonymization. Outside Customers, services store customerId, not the name; logs and metrics carry only identifiers (06-01); Jaeger traces carry no bodies.
• Encryption at rest. On managed databases it is enabled by default (encrypted disks); for especially sensitive columns you can encrypt at the application level with a key from the secrets manager, at the cost of not being able to index them. Backups encrypted and with the same retention.
• Right to erasure. The flow from 02-04: customers-service anonymizes and publishes customer.deleted; Orders deletes customers_ref and anonymizes addresses of old orders that tax regulations require keeping; Notifications stores nothing. It is one more use case, with an automated test.
• Card data: NEVER at TechCorp. The browser sends the card directly to the payment provider (the provider's form or SDK); TechCorp receives a token (tok_…) that payments-service uses to charge. That way the PCI DSS scope is reduced to the minimum (SAQ A). Neither the number, nor the CVV, nor even "the last four digits" unless the provider returns them already masked. *.card in redact is a safety net in case someone slips up, not a permission.
• Record of processing activities and retention: each service documents which personal data it stores, why and for how long (table in its README), and a CronJob applies the retention (e.g. anonymizing addresses of orders older than 5 years).

The logs from 06-01 tell what happened technically; the audit trail tells who did what to what, and must be provable months later. Auditable actions at TechCorp: cancelling an order (who, reason), changing a price in Catalog, manually changing a payment's status, reprocessing the DLQ (scripts/reprocessDlq.js, 06-03), an operator accessing a customer's data, changing roles in Keycloak. Requirements: immutable (insert-only, no UPDATE/DELETE for the svc_* user), separate from operational logs (different retention: years versus weeks), and correlatable with X-Request-Id and the token's sub (X-User-Id, 07-01).

At high volume, the table is replaced by audit.* events sent to a write-only store (or the structured log with type: 'audit' sent to a Loki tenant with long retention and no deletion); what matters is the separation and immutability, not the technology. detail contains no personal data: identifiers and business values.

And application security tests are ordinary tests: the test/orders.auth.test.js from 07-01 (401/403/404) and cases such as "an id that does not match the pattern returns 400", "a body with an unknown field returns 400", "?category[$ne]=x returns 400" live in Jest alongside the rest and protect against regressions.

Sooner or later someone will find something. What TechCorp leaves prepared:

1. Reporting channel: [email protected] and a /.well-known/security.txt file on shop.techcorp.example (RFC 9116) with contact and policy; public acknowledgment (no formal reward in phase 1).
2. Triage: severity with CVSS; critical/high → security incident following the process from 06-05 (channel, owner, timeline), even if there is no service outage.
3. Patching: branch from main, a test that reproduces the flaw, deployment through the normal pipeline (canary if applicable, 05-04); vulnerable dependency → update or temporary mitigation (block the route at the gateway).
4. Communication: internal (all teams, because the same pattern may exist in another service) and, if personal data was accessed, notification to the supervisory authority within 72 hours and to those affected under the GDPR: a decision of the data protection officer, not of the technical team.
5. Blameless postmortem (06-05) with actions: new Semgrep rule, new item on the checklist, regression test.

This table is added to techcorp/node-service-template/SECURITY.md and to the pull request template; each service reviews it when created and on every relevant change:

• Validating only the body and leaving req.params.id and req.query without a schema: half of the injections and BOLA come in through there.
• Permissive schemas (z.object without .strict(), z.string() without max) that accept any field or 10 MB strings: validation must be as strict as the OpenAPI contract.
• "Sanitizing" instead of rejecting: stripping "dangerous" characters with home-grown regular expressions never covers every case and silently changes the user's data.
• Trusting third-party responses because "it's the payment provider": API10 exists because third parties make mistakes too, and get attacked too.
• Logging the request body at info "for debugging" and discovering weeks later that Loki is storing addresses and emails.
• Silencing npm audit with --force or audit-level=critical so that CI passes: every exception, documented with a date.
• Treating the audit trail as "just another log" and deleting it after 30 days with Loki's retention.
• Tip: every rule in this lesson that can be automated (lint, Semgrep, gitleaks, ZAP, Jest test) is worth more than the same rule in a document; the checklist is for what cannot be automated.

Exercise 1. A developer proposes adding to catalog-service the route GET /v1/products/search?filter=<json>, which receives a MongoDB filter object "so the front end can run flexible queries". Explain the problem using the OWASP numbering and propose a secure design that covers the real needs (search by text, category and price range).

Exercise 2. Write the zod schema for POST /v1/orders/{id}/cancellation (03-01: reason from an allowed list, optional comment) including the route parameter, and the corresponding audit record with createAudit.

Exercise 3. Marta asks whether, to comply with the GDPR, it is enough for Notifications to "delete the email when customer.deleted arrives". List which other places in the platform may contain Ana's email and which measure applies to each.

Solution 1. It is a textbook API8/API3 and NoSQL injection: an arbitrary filter object allows { "$where": "..." }, { "price": { "$gt": 0 } } on fields that should not be filterable, exposing internal fields (supplierCost), unindexed queries that bring Mongo down (API4) and, with $lookup in aggregations, reading other collections. Secure design: named parameters and a closed schema, Search = z.object({ q: z.string().trim().min(2).max(60).optional(), category: z.string().regex(/^[a-z-]{1,40}$/).optional(), priceMin: z.coerce.number().min(0).optional(), priceMax: z.coerce.number().max(100000).optional(), limit: ...max 100, cursor }).strict(); the repository builds the filter with fixed keys ({ normalizedName: { $regex: escape(q), $options: 'i' } } with q escaped or, better, a text index and $text: { $search: q }; priceCents: { $gte, $lte }); indexed fields only; and the route returns the usual toDto DTO. If the front end needs something more flexible, that is a case for GraphQL in the BFF (03-03), with a typed schema, not for passing Mongo objects around.

Solution 2.

The comment does not go into the audit trail (free text from the user, may contain personal data): only whether it exists. And the audit record is written after the transition, inside the same transaction if the repository allows it, so as not to audit cancellations that failed.

Solution 3. Places and measures: (1) Customers database: anonymize the row (not delete, for integrity and tax obligations), source of the event. (2) customers_ref in Orders (02-04): delete the row and anonymize shipping_address of old orders on receiving customer.deleted. (3) order.created messages in RabbitMQ queues, .retry and .dlq: short retention and purge (section 8); if there are DLQ messages for the customer, they are processed or discarded. (4) Logs in Loki: there should be no email thanks to redact and the rule of not logging it; if an audit finds one, it is an incident (section 11) and it must be deleted from the store. (5) Traces in Jaeger: no bodies or personal data by design (06-02); check custom span attributes. (6) Backups: they are not edited; it is documented that the data disappears when the backup's retention expires (and it is anonymized on restore). (7) Keycloak: delete or disable the user (the sub), which is where the login email lives. (8) Notifications' email provider (if it keeps a sending history): configure minimal retention or request deletion through its API. (9) The audit table: it must not contain emails (only user_id), and by design it is kept. The answer to Marta: "delete in Notifications" is one of nine actions, which is why the right to erasure is a use case with a list and a test, not a DELETE.

This lesson has turned "code" security into concrete TechCorp practices: six principles (least privilege, defense in depth, fail secure, minimal surface, security by design, shift left); the OWASP API Security Top 10 read through its own cases and remedies that already existed (resource owner, DTOs, limit ≤ 100, rate limit, CORS, OpenAPI and Pact) or have been added; zod .strict() schemas with pattern-based ids (^ord-[0-9a-f]{8}$), allowlists and limits, also on route and query parameters, with express.json({ limit: '100kb' }); parameterized queries in pg, MongoDB filters with fixed keys, execFile and logging by fields; helmet on gateway and services; npm ci, npm audit, Dependabot and SBOM; gitleaks in CI and rotation on any leak; practical GDPR (minimization with the decision to keep email in order.created under conditions, pseudonymization, encryption at rest, customer.deleted, retention, and never card data: provider tokenization and minimal PCI DSS scope); an immutable, separate audit trail with createAudit correlated by user_id and request_id; SAST with ESLint/Semgrep, DAST with ZAP against staging, checklist review and an annual pentest; a response process with security.txt and GDPR notification; and the checklist that is now part of node-service-template. The last layer remains, the one that holds up all the others: the image that runs the code, the pod that contains it, the secrets that reach it, the network around it and the cluster's permissions. That is the topic of the next lesson: container and Kubernetes security.