Attacks and defenses

Most attacks on a web app are not clever. They are automated, cheap, and aimed at every site on the internet at once. Each has a standard defense.

Injection

An attacker types something into a form that the app pastes into a database query or a page. If the input becomes part of the command, it can read or delete data (SQL injection) or run script in other visitors' browsers (XSS). Defense: never build commands from text. Parameterize queries, and escape everything rendered into a page.

Brute force and credential stuffing

Guessing passwords, or replaying email and password pairs leaked from other sites. Defense: rate limits on login, lockouts after repeated failures, a password policy that rules out the most common guesses, and MFA, a second factor from an authenticator app that a leaked password cannot satisfy.

Bots

Scripts that sign up thousands of fake accounts, scrape prices, or submit spam. Defense: a bot check on the forms that matter (sign in, sign up, password reset), plus rate limits per address.

Denial of service

Flooding a site with requests until it cannot answer real ones. Defense: a WAF (web application firewall) in front of the app, which recognizes attack patterns and abusive addresses and drops them before they reach your server.

Secrets

The quiet failure: an API key committed to a repository, a database password in a page. Defense: keep secrets on the server, store only hashes of keys, and revoke first, investigate second.

Where DontCode fits

The platform WAF blocks attacks automatically, and the Analytics page shows what it blocked. Under Users, Security, one switch turns on the bot check for sign in, sign up, and password reset, and the password policy and Two-Step Verification settings live on the same page. Queries through the public API are parameterized on the server, OAuth secrets are write-only, and API keys are stored as hashes.