Security

A hash function such as SHA-256 reads data of any size (a password, a file, a whole disk image) and outputs a fixed-size value: 256 bits for SHA-256, usually written as 64 hexadecimal characters. Change a single letter of the input and the output changes completely. A good hash is one-way, so the input cannot be worked out from the output, and collision-resistant, so in practice nobody can find two inputs that share a hash.

Hashes prove that data has not changed. Download pages publish checksums, Git names every commit by a hash of its contents, build tools put content hashes in file names so browsers can cache them safely, and digital signatures sign a hash rather than the whole file. MD5 and SHA-1 are broken for security use because collisions can be manufactured; SHA-256, SHA-3 and BLAKE3 are the usual choices today.

Hashing is not encryption: there is no key and nothing to decrypt. Fast hashes are also the wrong tool for passwords, which need deliberately slow password hashing.

When someone signs up, the server runs their password through a password hashing function and stores only the result. At login it hashes the typed password the same way and compares the two. Each password gets a random salt (a unique value mixed in before hashing), so two people with the same password end up with different hashes and precomputed lookup tables, known as rainbow tables, are useless.

These functions are deliberately slow and, in the newer designs, memory-hungry, so guessing billions of passwords on graphics cards becomes impractical. OWASP recommends Argon2id (winner of the 2015 Password Hashing Competition) first, then scrypt, bcrypt for older systems, and PBKDF2 where FIPS-140 compliance is required. Plain SHA-256, MD5 or reversible encryption are not acceptable for passwords, because they are far too fast or can be undone.

Good libraries and frameworks (the argon2 and bcrypt packages, Django, Laravel, ASP.NET Identity) generate and store the salt for you, and the cost setting can be raised over time. bcrypt only reads the first 72 bytes of a password. Hosted services such as Supabase Auth, Firebase Auth and Auth0 handle all of this, and passkeys remove the stored password altogether.

Symmetric encryption uses one secret key to lock and unlock. AES-GCM and ChaCha20-Poly1305 are the standard choices, and both also detect tampering. Asymmetric (public-key) encryption uses a pair: anyone can lock data with the public key, but only the matching private key opens it. RSA and elliptic-curve schemes are asymmetric and much slower than symmetric ciphers, so real systems use them to agree on or protect a symmetric key, then encrypt the data itself with that key.

In transit means data moving over a network, protected by TLS (the S in HTTPS), SSH or a VPN. At rest means data sitting on a disk or in a database, protected by disk encryption such as BitLocker or FileVault, or by the storage service; the major cloud storage services encrypt at rest by default. End-to-end encryption, as in Signal and WhatsApp, means only the people talking hold the keys, so even the service in the middle cannot read the messages.

Encryption is only as strong as the handling of its keys. Keys belong in a key management service (such as AWS KMS or Google Cloud KMS) or the OS keychain, never beside the data they protect. Inventing your own cipher, or reusing a nonce with AES-GCM, are classic ways to break otherwise sound encryption.

HMAC (hash-based message authentication code) mixes a secret key into a hash function such as SHA-256. The sender computes HMAC-SHA256 over the exact bytes of a message and sends the result as a signature; the receiver, who holds the same secret, recomputes it and compares. Anyone can read the message, but without the secret nobody can produce a matching signature, and changing a single byte breaks it.

Webhooks are the everyday use. Stripe sends a Stripe-Signature header carrying a signature over a timestamp and the request body. Razorpay sends X-Razorpay-Signature on webhooks, and its checkout returns a signature over the order and payment ids that your server must check before marking an order paid. GitHub (X-Hub-Signature-256) and Shopify work the same way, and JSON Web Tokens signed with HS256 use HMAC too.

Verify against the raw request body before any JSON parsing changes it, compare signatures with a constant-time function so timing leaks nothing, and reject old timestamps to stop replayed requests. HMAC proves who sent a message but does not hide it; that is the job of encryption.

Most services hand out two kinds of key. Publishable keys (Stripe's pk_ keys, Razorpay's key id, a Supabase publishable or anon key, a Firebase web config) are meant to sit in a website or app and only identify the account. Secret keys (Stripe's sk_ keys, Razorpay's key secret, Supabase's service role key, an OpenAI key) can move money, read every record or run up a bill, so they are only ever used from a server.

On a server, secrets live in environment variables: in development they come from a .env file listed in .gitignore, and in production from the host's settings or a secrets manager such as AWS Secrets Manager, Google Secret Manager, Doppler or Infisical. CI systems such as GitHub Actions keep their own encrypted secrets. Anything shipped to a browser or phone can be read by its user, and any variable prefixed NEXT_PUBLIC_ (Next.js) or VITE_ (Vite) is built into the code sent to browsers, so those prefixes are only for values that may be public.

Leaked keys are found fast, because bots scan public repositories for them; GitHub secret scanning and tools such as gitleaks can catch many before or just after they are pushed. Deleting a leaked key from the code is not enough, because it survives in Git history and in copies; revoke it and issue a new one. Keys scoped to only the permissions they need, rotated regularly, limit the damage when one escapes.

Each platform has one: Keychain on macOS and iOS, Credential Manager on Windows (protected by the Data Protection API, DPAPI), and the Secret Service API on Linux desktops, provided by GNOME Keyring or KDE Wallet. Android has the Keystore, which holds encryption keys, often inside secure hardware, rather than the secrets themselves. Entries are encrypted with keys tied to the user's login, so other accounts on the machine cannot read them, and macOS, iOS and Android also keep each app's entries apart from other apps.

Desktop apps use it for refresh tokens, API keys a user has pasted in, database passwords and encryption keys. Electron's safeStorage API and the Rust keyring crate (often used in Tauri apps) build on these platform stores, so an app does not have to handle each one itself. The alternative, a token in a plain config file, sits unencrypted on disk, where it can leak through backups, synced folders or a lost laptop.

The keychain protects secrets at rest on the user's own machine. It does not make a key that ships inside the app safe: anything compiled into an app can still be pulled out of the app itself.

OWASP (the Open Worldwide Application Security Project) is a non-profit community that publishes free security guidance. Its Top 10 is built from data on real application tests plus a survey of practitioners, and it is refreshed every few years. The 2025 edition, in order: broken access control, security misconfiguration, software supply chain failures, cryptographic failures, injection (which covers XSS and SQL injection), insecure design, authentication failures, software or data integrity failures, security logging and alerting failures, and mishandling of exceptional conditions.

Broken access control has held the top spot since 2021. It means a user reaching data or actions that should be off limits, for example seeing someone else's order by changing an id in a URL. The fix is to check permissions on the server for every request, not to hide buttons in the interface.

The Top 10 is an awareness list rather than a full standard. For detailed requirements OWASP publishes the ASVS (Application Security Verification Standard) and the free Cheat Sheet Series, and there are separate Top 10 lists for APIs, mobile apps and LLM applications.

XSS happens when text from a user, such as a comment, a profile name or a URL parameter, is placed into a page as HTML instead of as plain text. The browser cannot tell the attacker's script from the site's own, so it runs with the site's full access: it can read what the page shows, send requests as the victim, change the page or redirect them. Stored XSS is saved on the server and hits everyone who views it, reflected XSS bounces off a crafted link, and DOM-based XSS happens entirely in front-end JavaScript.

The core defence is output encoding: show user text as text. React, Vue, Angular and Svelte do this by default, so most of the risk comes from escape hatches such as dangerouslySetInnerHTML in React, v-html in Vue or innerHTML in plain JavaScript. When real HTML must be shown, for example from a rich text editor or rendered Markdown, it is cleaned first with a sanitiser such as DOMPurify.

A Content Security Policy then limits which scripts may run at all, as a second line of defence, and HttpOnly cookies stop scripts from reading the session cookie, although an injected script can still act inside the page. XSS sits in the injection category of the OWASP Top 10.

Browsers attach a site's cookies to requests sent to that site, even when a different site starts the request. If a bank changed a payee through a plain form post checked only by a session cookie, a malicious page could submit that form in the background and the bank would see a valid, signed-in request. The attacker never sees the response; the damage is the action itself.

Defences stack. Session cookies set to SameSite=Lax or Strict are left off most cross-site requests. A CSRF token, a random value tied to the session that must come back with every form or state-changing request, proves the request came from your own pages, and Django, Laravel and Rails check these tokens by default. Checking the Origin header helps too, and Next.js Server Actions accept only POST requests whose origin matches the host.

Actions that change data should never run on GET requests. APIs that authenticate with a token in the Authorization header rather than a cookie are not exposed to classic CSRF, because browsers do not add that header on their own. CORS is not a CSRF defence on its own: simple form posts are sent without asking, and CORS mainly controls who may read the response.

It happens when code builds a query by gluing user input into the SQL text, for example adding whatever was typed into a search box straight after WHERE name =. A visitor who types a quote character followed by SQL of their own can then change what the query means: skip a password check, read another table or delete rows. It has been well known since the late 1990s and still turns up, usually in hand-written queries.

The fix is parameterised queries (prepared statements): the SQL is sent with placeholders such as $1 or ?, and the values travel separately, so the database never mistakes data for code. ORMs and query builders such as Prisma, Drizzle, SQLAlchemy and Django's ORM do this automatically, but raw-query helpers that take a plain string, such as Prisma's $queryRawUnsafe, bring the risk back if input is pasted in.

Extra layers limit the damage: a database user with only the permissions the app needs, error pages that do not reveal SQL, and a WAF that blocks common patterns. NoSQL databases have their own form of injection when user input is passed straight into a query object.

The server sends a Content-Security-Policy header that lists the allowed sources for each type of content: script-src for JavaScript, style-src for CSS, img-src for images, connect-src for fetch calls, frame-ancestors for who may embed the page (the modern defence against clickjacking), and so on. The browser blocks anything that does not match and can report violations to an address you choose.

The strongest setup is a strict policy based on nonces or hashes: each response gets a fresh random nonce, only script tags carrying it may run, and inline scripts an attacker injects are refused. Allow-lists of whole domains are weaker, because a permitted domain may host scripts an attacker can reuse, and 'unsafe-inline' switches off most of the protection. Third-party widgets need their origins allowed; Turnstile, for example, needs challenges.cloudflare.com.

Rolling a policy out with the Content-Security-Policy-Report-Only header first shows what would break without blocking anything. CSP can also be set in a meta tag, although a few directives such as frame-ancestors only work as a header. It is a safety net for XSS, not a replacement for escaping output.

Call DOMPurify.sanitize(html) and it parses the string with the browser's own HTML parser, walks the result and removes script tags, event-handler attributes such as onclick, javascript: links and other dangerous parts, while keeping ordinary markup such as paragraphs, links, lists and images. It handles HTML, SVG and MathML, and it can be configured to allow or forbid particular tags and attributes.

It is the usual choice whenever an app must display HTML it did not write: rendered Markdown, rich text from an editor such as Tiptap, emails or content from a CMS. The security firm Cure53 maintains it and updates it as new ways of smuggling script past sanitisers are found. It needs a DOM, so on a server it runs with jsdom or through the isomorphic-dompurify wrapper.

Browsers have started to ship a built-in Sanitizer API (element.setHTML); until every browser a site supports has it, DOMPurify remains the portable choice. Clean the HTML right before it is inserted, and keep the library updated.

A CAPTCHA protects sign-up, login, contact and checkout forms from bots that create fake accounts, try stolen passwords or flood inboxes. Older versions asked people to read warped text or pick out traffic lights. Modern ones such as Cloudflare Turnstile, Google reCAPTCHA and hCaptcha mostly run quiet checks in the browser (small computations and signals about the browser and its behaviour) and only show a checkbox or puzzle when something looks wrong.

Turnstile has three modes: Managed (a checkbox appears only when needed), Non-Interactive and Invisible. It works on any website, whether or not the site runs through Cloudflare's network. The widget gives the browser a token, the form sends it to your server, and the server confirms it with Cloudflare's Siteverify API using the secret key. Tokens are single use and expire after five minutes, and a form that skips the server-side check is not protected at all.

Turnstile does not use visitor data for ad targeting. Google's reCAPTCHA is free up to 10,000 assessments a month per organisation and then charges, and hCaptcha has a free plan and paid tiers. None of them stops every bot, since paid solving services and real people in click farms get through, so CAPTCHAs work best alongside rate limits and checks on the server.

A WAF inspects each HTTP request before it reaches your server and blocks those that match known attack patterns: SQL injection and XSS attempts, probes for known vulnerable plugins, bad bots and abusive request rates. Rules come as managed rulesets kept up to date by the vendor (several are based on the open-source OWASP Core Rule Set) plus custom rules you write, such as closing the admin area to other countries or limiting login attempts per minute.

A distributed denial-of-service (DDoS) attack sends more traffic than a server or network can handle, from thousands of machines at once. Protection works at the network layer (floods of packets) and at the application layer (floods of real-looking HTTP requests), and relies on a provider with enough capacity, spread across many data centres, to absorb the flood. Cloudflare includes unmetered DDoS protection on every plan, the free one included, and AWS Shield Standard is automatic for AWS customers.

Other options include AWS WAF, Google Cloud Armor, Azure WAF, Akamai and Fastly, plus the open-source ModSecurity and Coraza engines. AWS WAF charges about $5 a month per web ACL (a set of rules), $1 a month per rule and $0.60 per million requests; AWS Shield Advanced costs about $3,000 a month on a one-year commitment. A WAF buys time but does not fix the bug underneath, and the origin server should accept traffic only from the WAF so that nobody can go around it.

A programme publishes a policy: which domains and apps are in scope, what is off limits (denial-of-service, social engineering, other users' data), how to report, and how much each severity pays. Researchers test within those rules and send reports; the company or the platform's triage team reproduces each one, rejects duplicates, and pays a bounty once a finding is confirmed. A safe harbour clause promises not to take legal action against researchers who follow the rules.

A vulnerability disclosure programme (VDP) is the unpaid version: a clear, safe way to report problems, often announced in a security.txt file at /.well-known/security.txt, a format standardised as RFC 9116. Many companies start with a VDP and add rewards later. Programmes can be private, with invited researchers only, or public.

Large companies such as Google, Microsoft and Apple run their own programmes, while HackerOne, Bugcrowd, Intigriti and YesWeHack host programmes for others and handle triage and payments. Researchers join the platforms free, and their testing is authorised only for what each programme's policy allows.

A pentest starts with a scope and rules of engagement: which systems are in, which test accounts to use, the dates, and what is off limits, all signed off by someone with authority over those systems. Testers then work through the target by hand and with tools such as Burp Suite, following methods like the OWASP Web Security Testing Guide. Black-box tests start with no inside knowledge, grey-box tests get user accounts, and white-box tests also see the source code.

The deliverable is a report that ranks each finding by severity (often with a CVSS score), explains the impact in plain terms, gives developers enough detail to reproduce it and suggests fixes. A retest after the fixes confirms they worked. The report is often what customers, investors and auditors ask for: PCI DSS requires penetration testing at least once a year and after significant changes, and SOC 2 and ISO 27001 audits commonly expect one.

A vulnerability scan is automated and finds known issues quickly; a pentest adds human judgement and catches broken business logic, such as paying for one item and receiving ten. A red team exercise goes further and tests whether defenders notice a realistic, stealthy attack.

An intercepting proxy such as Burp Suite, mitmproxy, ZAP (formerly OWASP ZAP), Charles or Fiddler runs on the tester's computer, and the browser, phone or app under test is pointed at it. Every HTTP request passes through, so it can be read, paused, edited and replayed. To read HTTPS, the tester installs the proxy's own certificate authority on the test device, which lets the proxy decrypt and re-encrypt the traffic; a device without that certificate shows warnings instead, which is exactly what TLS is designed to do.

The main lesson is that anything the client sends can be changed. If a price, a user id or an 'is admin' flag travels from the app and the server trusts it, anyone with a proxy can alter it. Interception also shows whether an app leaks tokens or personal data, and what its third-party SDKs send. Browser DevTools cover the basics for websites; proxies add editing, replay, automated scanning and mobile apps.

Mobile platforms make it harder on purpose: apps built for Android 7 and later ignore user-installed certificates unless their network security configuration allows them, and apps with certificate pinning accept only their own server's certificate. Teams usually allow interception in debug builds of their own apps. It is legitimate on your own devices and systems, or ones you have written permission to test; intercepting other people's traffic without consent is against the law in most places.

Compiled programs are machine code, but tools can turn them back into something readable. A disassembler shows the processor instructions and a decompiler rebuilds approximate source code. Ghidra (released as open source by the US National Security Agency in 2019), IDA Pro, Binary Ninja and radare2 handle native programs, jadx and apktool open Android apps, and ILSpy does the same for .NET. Debuggers and instrumentation tools such as Frida watch a program while it runs.

Security teams use it to understand malware and write detections for it, to find vulnerabilities in closed-source software they are authorised to test, and to check their own released apps for hard-coded keys or leftover debug code. It is also how undocumented file formats and protocols are worked out, so that other software can interoperate with them. Android apps, .NET programs and JavaScript are easier to read back than native code, because they ship as bytecode or source.

The law varies by country and licences often restrict it. Many places allow it for interoperability or good-faith security research under conditions, so it is done on software you own or are allowed to analyse, with legal advice when in doubt. Malware is analysed in isolated virtual machines, never on everyday computers.

On Android, R8 shrinks a release build and renames classes and methods to short, meaningless names, keeping a mapping file that turns crash reports back into real names (Play Console and crash reporters accept it). JavaScript minifiers such as Terser, esbuild and SWC shorten names and strip whitespace, mainly to save size. Heavier tools such as javascript-obfuscator and commercial protectors (DexGuard and iXGuard from Guardsquare, Jscrambler) add encrypted strings, scrambled control flow and checks that detect tampering or debuggers.

Obfuscation raises the cost of copying code or finding weak spots, and it hides business logic from casual inspection. It does not hide secrets: an API key inside an app can be pulled out however well the code is scrambled, so secrets stay on a server. Heavy obfuscation also costs size, speed and debugging time. Publishing source maps undoes minification, so they are usually uploaded privately to an error tracker instead.

A YARA rule has a name, optional metadata, a set of strings to look for (plain text, hex byte patterns or regular expressions) and a condition such as 'any two of these strings, in a file smaller than 1 MB'. Analysts write rules after studying a sample, often with reverse engineering, and share them so others can find the same family even when file hashes differ. Antivirus engines, incident responders, VirusTotal and many security products run YARA rules.

YARA was created at VirusTotal and is free and open source. YARA-X, a rewrite in Rust by the same team, became the stable successor in 2025 and runs most existing rules unchanged, while the original YARA now receives only bug fixes. Rules are not limited to malware: they can match any file with recognisable content.