CY2: Authorised assessment: settings, packages and reports
Reviewing settings
🎯You'll be able to
Spot risky settings, such as debug mode, written-in secrets, weak cookie flags, long sessions and open cross-origin access.
🏠The everyday picture
A new flat can have strong doors but a spare key under the mat, a window left open, and the alarm switched to "test". None of them is a broken lock; all of them are settings.
📘What it really is
- Debug mode shows detailed errors, sometimes with code, paths and settings. It belongs on a developer's computer only.
-
Secrets in files: keys and passwords written into settings or code end up in backups, copies and version history. They belong in the environment or a secrets manager, and a key that has been exposed must be replaced, not just moved.
-
Cookie flags:
Securesends the cookie over HTTPS only;HttpOnlystops page scripts reading it;SameSitelimits when other sites can send it. -
Session length: a session that lasts 30 days gives a stolen cookie a long life. A working day is common for staff apps.
-
CORS (cross-origin resource sharing):
*lets any website's scripts call the API from a user's browser. List only the sites that need it. -
Baselines: compare against a written list of safe values, and record each difference as a finding.
📝A worked example
Input: data/assessment-target/settings.json from the kit.
Steps:
- Read each setting.
"debug": true, asecret_keywritten in the file,"session_hours": 720,cookie_secureandcookie_httponlyfalse, and"cors_allow_origins": ["*"]. - Compare with the baseline in
docs/FORMATS.md, which gives a rule ID and severity for each: for exampleCFG-DEBUGmedium,CFG-SECREThigh. - Write each as a finding with the rule, the evidence (the setting and value) and the fix.
Expected output: five settings findings, one each for debug, secret, cookie, session length and CORS.
🌍Where it's used
- Cloud storage reviews look for buckets set to public.
- Release checklists confirm debug mode is off.
- Secret scanners in code hosting services look for keys in commits.
📝Case scenario
An online learning company left debug mode on after a busy release. An error page showed the database password to anyone who triggered it. They turned debug off within an hour, but also had to change the password, because it had already been on screen.
🖱️Try it
In the kit, open data/assessment-target/settings.json and config/settings.json side by side. Success: you can name two settings
the old server had that the starter's config file still repeats.
⚠️Common mistakes
- Moving an exposed secret without replacing it. Sign: the same key, now in the environment. Fix: replace it, then move it.
- Checking only that a setting exists. Sign:
cookie_securepresent but false. Fix: check the value. - Treating
*as harmless. Sign: "it's only for convenience". Fix: list allowed sites.
🛠️For your project
In Project 1 you write check_settings in assess/assess.py. Tests 1 and 2 check it finds all five problems, and finds nothing in
safe settings.
✅Quick check
Why isn't moving a leaked key into an environment variable enough?
Show the answer
The old key has already been exposed and must be replaced.
What does the HttpOnly cookie flag stop?
Show the answer
Scripts on the page reading the cookie.