Dumb ways to ship.
Built in a weekend.

The OTP is generated in the browser and printed on the page (and in the console). The whole point of a one-time code is that it arrives through a different channel you control. Generate and verify it on the server; never send it back in the response.

To know a password is "taken", the app must compare it against everyone else's, which means passwords are stored in plain text (or unsalted). And it then tells you whose account it opens. Hash passwords with a slow, salted algorithm (bcrypt, scrypt, argon2) and never compare across users.

Anything that runs in the browser can be read by the person using it. Credentials, checks and "secret" logic in frontend code are public. Authentication has to happen on a server that the user can't see or modify.

The request to the AI provider carries the company's secret API key, so anyone can open DevTools, copy it, and run up the bill. Keep provider keys on a server and have the browser talk to your own endpoint, with auth and rate limits.

Prices, discounts and totals sent from the client are suggestions from a stranger. The server should look up the price itself from the item ID and calculate the total.

This is an IDOR (insecure direct object reference). The server returns any invoice whose ID you ask for without checking it belongs to you. Every record lookup needs an ownership check, and sequential IDs make the problem easy to exploit.

The coupon is never marked as used, and nothing stops the total going below zero. Redeem coupons on the server, record them per account and order, and clamp totals.

Permissions must come from the server-side session, not from anything the user can type: URLs, cookies they can edit, localStorage, or hidden form fields.

Pasting user input into SQL lets the input become SQL. Try ' OR '1'='1. Always use parameterized queries or an ORM's bound parameters.

Rendering user content as HTML lets anyone run scripts in every visitor's browser, stealing sessions or acting as them. (This demo only simulates it.) Render text with textContent, or sanitize with a library like DOMPurify.

Stack traces reveal file paths, library versions and, all too often, environment variables with credentials. Show users a generic error, log the details on the server, and keep secrets out of anything that could be printed.

The trial's expiry date lives in the user's own browser, so they can just change it. Subscription and trial state belong in your database, checked on every request that uses a paid feature.

There are only 10,000 four-digit PINs, so without rate limiting a script tries them all in seconds. Limit attempts per account and IP, add delays or lockouts, and use longer secrets.

The API response includes the reset token, so anyone can reset anyone's password without access to their inbox. Only deliver tokens through the email channel, make them single-use and short-lived, and return the same response whether or not the account exists.

Encoding is not encryption, and neither one stops tampering. Sessions should be an opaque random ID looked up on the server, or a token signed with a secret key (and the signature actually verified).

Binary floating point can't represent 0.1 exactly, so 0.1 + 0.2 !== 0.3. Store money as integer cents (or use a decimal type) and only format it for display.

Accepting any file type and serving it from your domain lets attackers upload scripts, HTML pages or executables. Check the real file contents (not only the extension), rename files, and serve uploads from a separate domain with safe headers.

robots.txt is public, and listing "secret" paths there is a map for attackers. Hidden URLs aren't access control; protect admin pages with real authentication.

This is a race condition: several requests all pass the balance check before any of them deducts. Do the check and the update atomically, for example in one database transaction with a row lock, or a conditional update like UPDATE … WHERE balance >= 100.