Security Considerations

The third column is the worked team's own mapping of its controls to the categories, not OWASP's. The S numbers refer to the security design table at the end of this chapter.

Passwords

Storing them

A password must never be stored as it was typed, and never with a fast hash such as SHA-256, which lets an attacker who steals the table try billions of guesses a second. OWASP's Password Storage Cheat Sheet says what to use instead: a slow, memory-hard algorithm, with a unique random salt for every password, so that two students with the same password have different hashes and no precomputed table helps. It ranks Argon2id first, and scrypt where Argon2id is not available.

The worked team uses scrypt, and the reason is written down. Node.js added Argon2 to its built-in crypto module only in version 24.7.0; on Node.js 22, which the project still supports (NFR-12), it does not exist, as the team confirmed by asking each installed version. scrypt exists on all of them. The cheat sheet lists five scrypt settings of equal strength; the team uses N = 2^14, r = 8, p = 5, which needs 16 MiB of memory per hash.

Each stored hash records its own algorithm and settings beside the salt, in the form scrypt$16384$8$5$salt$key. That makes the choice reversible: when Node.js 22 reaches its end of life, the team can move to Argon2id by re-hashing each password the next time its owner signs in, without breaking any password already stored. And a sign-in compares the computed hash with the stored one in constant time, so the time taken reveals nothing about how close a guess was.

Chapter 8 noted the legal side: under the Information Technology rules of 2011, a password is sensitive personal data, and section 43A of the Information Technology Act requires reasonable security practices for it. Hashing it this way is a large part of what "reasonable" means today.

The rules for choosing one

Two respected standards disagree about length. OWASP's Application Security Verification Standard, ASVS 5.0, requires at least 8 characters and strongly recommends 15. NIST's SP 800-63B-4 says that a password used as the only factor shall be at least 15 characters. Both say the same about everything else: no composition rules, no demand for a capital letter, a digit and a symbol, which make passwords harder to remember and no harder to guess, and a maximum long enough for passphrases.

The worked team chose 8 to 128 characters, with no composition rules, and wrote down why: the accounts guard lunch orders, not money; registration is open only to college email addresses; failed sign-ins are limited; and a student typing on a phone at the start of the break will not type 15 characters. That meets ASVS level 1, falls short of NIST's rule, and says so. A system guarding anything of real value should take 15.

Reading ASVS against the design found a gap: level 1 also requires that registration refuse at least the 3,000 most common passwords (6.2.4), and the first design did not. It is now part of the design, as control S5: registration will refuse any password on a list of common passwords, and the page will ask for a password used nowhere else. Chapter 46 builds and tests it.

Sessions

After a correct password, the server creates a session: 32 random bytes, 256 bits, given to the browser as a cookie called sid. The database stores only a SHA-256 hash of it, the decision recorded as ADR-3 (Chapter 36), so that a stolen copy of the sessions table cannot be used to sign in as anybody: the hash cannot be turned back into the cookie. Here a fast hash is right, unlike for passwords, because the token is long and random, with nothing to guess.

The cookie is:

• HttpOnly: page scripts cannot read it, so even an injected script could not steal it;
• SameSite=Lax: the browser does not send it with a form posted from another site;
• Secure whenever the site uses HTTPS: it is then never sent over plain HTTP (NFR-4);
• limited to 8 hours, and deleted from the database at sign-out, so a stolen cookie stops working.

Access control

Deny by default. Every API route states who may call it, with a guard that refuses anyone else: 401 if nobody is signed in, 403 for the wrong role (Chapter 30). A route with no guard is one of the few deliberately public ones: the menu, the slots, signing in and out, registering, and the health check.

Ownership, not just role. Being a student is not enough to see an order; it must be your order. The order service checks the owner on every read and every cancellation, and answers "not found" for anyone else's, so that it does not even confirm the order exists (NFR-5).

The rules decide who may move an order. A student may move an order only from placed to cancelled; only the counter staff and the owner may move it any other way (Chapter 23). That check is in the rules, not in the pages, because a page's buttons can be bypassed by anyone who sends the request directly.

Input: validate everything on the server

Every value that arrives is checked on the server, whatever the page already checked: the page's checks exist to help honest users, and an attacker does not use the page. Types, lengths, allowed values and ids are all checked in one place (Chapter 47); a request body over 10 kilobytes is refused before it is read; and the database's own constraints refuse anything that gets past both (Chapter 29).

SQL injection is prevented by never building SQL out of values: every value is sent to MySQL separately, as a placeholder. Where the text of a statement does vary, it varies only by pieces written in the code: how many placeholders there are, whether a slot filter is added, and, when the owner changes some of a menu item's fields, column names taken from a fixed list, never from the request.

Cross-site scripting is prevented by never adding any text to a page as HTML (Chapter 27), and, as a second defence, by a content security policy that forbids the browser to run any script except the site's own files.

Cross-site request forgery, another site making a signed-in student's browser send a request, is prevented three times over: every request that changes something must be JSON, which an ordinary form on another site cannot send; if the browser names the page the request came from, that page must be on this site; and the SameSite cookie is not sent with another site's form posts.

Secrets

Every secret, the database password first, lives in the .env file on the machine that runs the application, which the repository's .gitignore excludes; the repository holds only .env.example, with placeholder values (Chapter 28). A password once committed stays in the repository's history for ever, even after it is deleted from the file, so the rule is: never commit it, not even once.

The database account the application uses can reach only its own two databases, the real one and the tests', and nothing else on the server (Chapter 29). It has every privilege on those two, because the setup script must be able to rebuild them. A stricter design would give the running application a second account allowed only to read and write rows, never to change tables; for one canteen the team judged one account enough, and recorded the choice.

HTTPS, and the trial's weakness

Chapter 25 drew the trial deployment honestly: the phones reach the lab desktop over the college Wi-Fi with plain HTTP, because the machine has no public name or address and so no certificate the phones would trust. That is the largest security weakness of the trial, and the design says so:

• What is exposed: everything sent between a phone and the server: passwords at sign-in, the session cookie with every request, and the orders.
• To whom: anyone able to capture traffic on the same network.
• What limits it: sessions end after 8 hours or at sign-out; each password is hashed on the server, so the database itself never holds it; and the registration page will ask for a password used nowhere else (S5), so that one captured password does not open a student's other accounts.
• The fix: a public server with a name and a certificate, served over HTTPS, with the cookie's Secure flag turned on, COOKIE_SECURE=true, which also makes the server send a header telling browsers to use only HTTPS for the site (Chapters 58 and 60). The same move lifts the trial's other limit, that ordering works only on the college Wi-Fi.

A weakness written down with its reason, its limits and its fix is an engineering decision. The same weakness unmentioned is a hole the examiner finds.

Logging, and what is not logged

The server writes one line for every request, including every refused sign-in and every refusal of access, and logs unexpected errors in full; the browser is told only that something went wrong (Chapter 28). Passwords, cookies and request bodies are never logged. There is no alerting: nobody is paged when sign-ins fail in bursts. For one canteen the team accepted that and recorded it as a limitation.

Personal data

The system keeps the least personal data it can do its job with: a name, a college email address, a password hash and the orders (constraint C-6). No phone numbers, no payment details, no photographs. Chapter 8 set out the law: the Digital Personal Data Protection Act, 2023, whose main obligations come into force on 13 May 2027, and until then section 43A of the Information Technology Act. Collecting less is the cheapest security control there is: data never collected can never leak.

The worked security design

This is the table Module 2's security validation tests line by line (Chapter 65). Each control names where it lives in the code, so a reviewer can check it.

S16 has one recorded exception: registering with an address that already has an account answers "email taken", which reveals that the address is registered. The team accepted that, because only college addresses can register and the answer is the one a real student needs.

Do this for your project

1. List your assets, your likely attackers and your entry points.
2. Go through the OWASP Top 10 and write your answer to each category.
3. Hash passwords with Argon2id or scrypt at OWASP's settings, with a salt per password; never with a fast hash.
4. Choose your password rules from a standard, and write down where you differ from it and why.
5. Keep sessions server-side, with only a hash of the token stored and the cookie HttpOnly, SameSite and Secure under HTTPS.
6. Put a guard on every route, check ownership as well as role, and validate every input on the server.
7. Keep every secret out of the repository from the first commit.
8. Write your weaknesses down with their limits and fixes, and number every control so that testing can check it.

Mistakes that cost marks

Passwords stored in plain text, or hashed with MD5 or SHA-256. A fast hash is not password storage.

Checks only in the pages. Anyone can send a request without the page.

Role checks without ownership checks, so any student can read any order by changing the number.

SQL built by joining strings with values from the request.

A database password in the repository, even for one commit.

"Security: we used HTTPS", with nothing else, or claiming HTTPS the deployment does not have.

A list of controls with no threats, or threats with no controls.

Quick revision

• Start from assets, attackers and entry points; every control answers one.
• OWASP Top 10:2025: A01 Broken Access Control, A02 Security Misconfiguration, A03 Software Supply Chain Failures, A04 Cryptographic Failures, A05 Injection, A06 Insecure Design, A07 Authentication Failures, A08 Software or Data Integrity Failures, A09 Security Logging and Alerting Failures, A10 Mishandling of Exceptional Conditions.
• Passwords: Argon2id or scrypt, a salt per password, never a fast hash; the worked settings are scrypt N = 2^14, r = 8, p = 5.
• Password rules: ASVS at least 8 (15 recommended); NIST 15 for single-factor; no composition rules; refuse common passwords.
• Sessions: random token, only its hash stored, cookie HttpOnly, SameSite, Secure, limited life.
• Deny by default; ownership as well as role; validate on the server; placeholders for SQL; text, not HTML.
• Secrets never committed. Weaknesses written down with limits and fixes.

Questions you must be able to answer

1. Why must passwords not be stored with SHA-256, and what should be used instead? Because SHA-256 is fast, so an attacker with a stolen table can try billions of guesses a second. A slow, memory-hard password hashing algorithm should be used instead, Argon2id or scrypt, with a unique random salt for each password, as OWASP's Password Storage Cheat Sheet advises.

2. Why does the worked project use scrypt rather than Argon2id? Because Argon2 was added to Node.js's built-in crypto module only in version 24.7.0, and the project also supports Node.js 22, where it does not exist. scrypt, OWASP's second choice, exists on every supported version; and because each hash records its algorithm and settings, the passwords can be moved to Argon2id later, at each student's next sign-in.

3. How is the session cookie protected? It is a 256-bit random token, of which the database stores only a SHA-256 hash; it is HttpOnly, so scripts cannot read it; SameSite=Lax, so other sites' forms cannot send it; Secure whenever the site uses HTTPS; it expires after 8 hours and is deleted at sign-out.

4. How does the worked design prevent cross-site request forgery? Every request that changes something must be JSON, which an ordinary form on another site cannot send; if the browser names the page the request came from, it must be this site; and the SameSite cookie is not sent with another site's form posts.

5. What is the trial deployment's largest security weakness, and what is its fix? It serves plain HTTP over the college Wi-Fi, so passwords, session cookies and orders can be read by anyone able to capture traffic on that network. The fix is a public server with a name and a certificate, serving HTTPS, with the cookie's Secure flag on.

6. The worked team allows 8-character passwords although NIST says 15. Is that defensible? It is a recorded decision: it meets OWASP ASVS level 1, which requires 8 and recommends 15, and the team gave its reasons, low-value accounts, college-only registration, a limit on failed sign-ins and typing on phones, while stating that it falls short of NIST's rule for single-factor passwords and that a system guarding anything valuable should take 15.