Logs and security

Open My Learning →

1. 01 · Book chapter

   Draw the feedback loop ↗

   Separate collection, detection, policy, and local enforcement.

   Put it to work

   Draw the request path and policy path separately. Mark which part remains available when the central service is offline.

   Keep as evidence: A diagram with one explicit failure scenario for each boundary.

2. 02 · Book chapter

   Design logs without secrets ↗

   Keep useful operational evidence while excluding credentials and sensitive request data.

   Put it to work

   Create three synthetic requests containing a token, a query string, and a user identifier. Define the minimal fields your logs should retain.

   Keep as evidence: A logging contract and redacted sample records using synthetic values.

   Practice in the browser

   Review a logging change →

3. 03 · Book chapter

   Identify the actual client ↗

   Make proxy trust explicit before using an address in a blocking decision.

   Put it to work

   Work through a direct request, a trusted proxy, and a forged forwarding header from an untrusted peer.

   Keep as evidence: A table showing the accepted client address and trust decision for each case.

4. 04 · Book chapter

   Investigate in the right order ↗

   Distinguish missing evidence, an incorrect decision, and failed enforcement.

   Put it to work

   Write an incident checklist that traces one synthetic request through the complete loop before changing a policy.

   Keep as evidence: A runbook with observations, expected results, and a reversible next action.

Watch and put it to work.

• Securing NGINX Origins · 7:18 →

Pause and check

Keep the useful evidence, protect the boundary

Choose an answer for every scenario, then check your reasoning. Progress is saved only in this browser.

1. A request object gains a new secret-bearing property. Which logging design excludes it by default?

Spread every request field into the event Delete only today's known sensitive fields Construct a new event from an explicit allowlist

Explanation and further reading

An allowlist limits the event to its operational contract. A denylist can silently include a newly introduced credential or personal field.

Revisit the guide or chapter →

2. An untrusted direct client sends X-Forwarded-For. Which address should you trust for a blocking decision?

The first forwarded value regardless of the peer The observed peer according to an explicit proxy trust policy The last value because it looks recent

Explanation and further reading

A forwarding header is input. The peer and the configured trusted proxy chain determine whether it can describe the actual client.

Revisit the guide or chapter →

3. A request was not blocked as expected. What is the most useful first investigation?

Trace collection and decision and enforcement for that request Tighten all blocking rules immediately Assume the policy service is the only possible cause

Explanation and further reading

Missing evidence, an incorrect decision, and failed local enforcement are different failures. Following the complete loop identifies the boundary that needs attention.

Revisit the guide or chapter →

4. A request gains an API credential field next month. Which existing log policy needs no new denylist entry to exclude it?

An explicit operational-field allowlist Serialize the entire request Remove only the password field

Explanation and further reading

The event contract should construct permitted fields. A newly introduced secret should not silently expand what gets logged.

Revisit the guide or chapter →

5. A collector produces events faster than the consumer can process them. What must the overload policy state?

That memory is unlimited A queue limit and an explicit overflow or backpressure behavior Only the normal throughput

Explanation and further reading

Bounded queues make overload behavior observable. An explicit policy explains which evidence can be delayed or lost.

Revisit the guide or chapter →

6. A trusted proxy forwards a header originally supplied by an untrusted client. What must determine the accepted address?

The first address-shaped string The shortest value The explicit trust policy across the observed peer and forwarding chain

Explanation and further reading

Trust does not come from the header's appearance. Apply the configured proxy boundary to the complete request path.

Revisit the guide or chapter →

7. The central policy service is unavailable. Which question should the architecture answer?

What the local enforcement component does with its existing policy How to pretend the service is still online How to discard every local observation

Explanation and further reading

The feedback-loop design names collection, decisions, and local enforcement separately, including behavior when a dependency is unavailable.

Revisit the guide or chapter →

8. An error contains an authorization header. What should a diagnostic event retain?

The full error and header A sanitized reason and permitted correlation fields A copy of every request property

Explanation and further reading

Troubleshooting needs a bounded operational contract. Raw request-bearing errors can cross the same secret boundary as ordinary logs.

Revisit the guide or chapter →

9. A policy decision says block, but the request still succeeds. Which boundary needs inspection next?

Assume collection failed without checking Increase unrelated detector thresholds Trace delivery and application of the decision at local enforcement

Explanation and further reading

A correct decision does not prove enforcement. Follow the event through the complete loop to locate the failed boundary.

Revisit the guide or chapter →

10. Before changing a blocking rule during an incident, what should the runbook preserve?

The observed request path, expected behavior, and a reversible next action Only a statement that the rule is wrong Production credentials copied into the ticket

Explanation and further reading

Recording observations and a reversible action makes the diagnosis reviewable without introducing sensitive material into incident records.

Revisit the guide or chapter →

Your checklist is saved only on this device. Keep your own evidence alongside each exercise. Follow new guides →