Validate Every Input and Lock Down Your Database

Two defences that guard your data: validating every input the app receives (never trusting what comes from the browser), and configuring database access rules so each user can only read and write their own data. AI frequently ships apps that trust all input and leave the database open, which is how one crafted request dumps or corrupts everything.

Every input from a user is potentially hostile — too long, the wrong type, or crafted to trick your code or your database (injection). Validating on the server means malformed or malicious data is rejected before it does harm. Database access rules add a second wall: even if a check is missed in your app code, the database itself refuses to hand one user another user's rows. Defence in depth means a single mistake isn't a breach.

On every endpoint that accepts input and every table that holds user data — from the first feature. Validation belongs on the server even if the UI already checks, because the UI can be bypassed entirely.

There's no safe exception for a public app. For a local, single-user prototype with no network exposure the risk is lower, but the habits are cheap to keep even then.

Harden this app's data handling. (1) Add server-side validation to every endpoint that accepts input — reject wrong types, out-of-range values, and oversized payloads, and use parameterised queries so input can't be interpreted as code. (2) Configure database access rules (e.g. row-level security) so each user can only read and write their own records. Show me the validation on each route and the access rule on each table.

A form field is sent straight into a database query, so a crafted value lets an attacker read the whole users table. Switching to parameterised queries plus server-side validation blocks it, and adding row-level rules means even a slipped-through query only ever returns the current user's rows.

Validate against an explicit schema for each input (types, lengths, allowed values) rather than ad-hoc checks, sanitise anything that will be rendered back to prevent cross-site scripting, and set the database rules as the source of truth so application bugs can't over-expose data. Add a couple of tests that a user genuinely cannot reach another user's records.

• Trusting client-side validation alone, when the endpoint can be called directly with any payload.
• Building queries by pasting user input into strings instead of using parameterised queries, inviting injection.
• Leaving the database open with no per-user access rules, so any authenticated request can read everything.