Web Security Basics

Why it matters

Security defects break requirements you already test: data stays private, only its owner changes it, and pages show what users typed. The difference is that someone searches for them on purpose. A session cookie that scripts can read, or a form that another site can submit, turns one small defect into stolen accounts, changed orders and exposed personal data.

Penetration testers go deeper, but they usually test at fixed points, such as before a major release. A functional tester touches every form and every release, so basic checks during normal testing find these defects early, when fixing them is cheapest, and give the security team better information when it looks.

What a functional tester can check safely

To a server, a harmless test value and an attack can look the same, and testing without permission can break the law even with good intentions. So a functional tester stays on the observing side: read what the application sends, enter what a real user could enter, and report what you see. Proving that a weakness can be exploited is the security team’s job.

• Test only systems you own or have written permission to test, preferably a test environment; never third-party sites, and production only if the permission names it.
• Use your own test accounts. Never read, change or delete other people’s data, even when you find that you could.
• Use harmless markers such as <b>qa</b>, quotes and apostrophes; no script payloads, scanners or attack tools without the security team’s approval.
• Stop at the first sign of a weakness, keep the evidence and report it through your team’s restricted channel for security defects, with tokens and personal data masked.

HTTPS and cookie flags

HTTPS encrypts the traffic between browser and server and proves the server’s identity with a certificate; the next lesson, on HTTP and HTTPS, explains how. Without it, anyone on the network path can read and change pages, form data and cookies.

The cookie attributes from the lesson on cookies and web storage are security controls too. On the session cookie, Secure keeps it off unencrypted connections, HttpOnly hides it from scripts, including an injected one, and an explicit SameSite=Lax or Strict stops the browser from sending it with most requests that start on other sites. Check them in the Application panel or with the Cookie Analyzer.

• Every http:// address redirects to https:// (301 or 308) before any content is served or any cookie is set.
• No mixed content: an HTTPS page must not load scripts, styles or images over http://. Browsers block such requests or upgrade them to HTTPS, and the Console shows a warning.
• Strict-Transport-Security (HSTS, RFC 6797), for example max-age=31536000, makes the browser use only HTTPS for the host until it expires. Without it, a typed http:// address goes out unencrypted and can be intercepted before the redirect.
• Passwords, tokens and personal data never appear in URLs: URLs are kept in history and server logs and can leak to other sites in the Referer header.

Try it: Cookie Analyzer

Input handling, XSS and CSRF

Every value from outside is untrusted: form fields, URL parameters, headers, cookies, files. Safe applications defend on the server twice. On the way in, they validate against an allow-list of expected type, length and format; browser checks are only a convenience. On the way out, they encode for the context — in HTML, < becomes <, so it is shown, not interpreted — and pass values to the database as parameters, never as glued-in text. Validation alone is not enough: O'Brien is valid input, so safety comes from how output is written.

Cross-site scripting (XSS) is the result of missing or wrong output encoding: input becomes markup, so a script an attacker typed runs in the victim’s browser with the victim’s session. It is stored when the value is saved and shown to others later, reflected when the response echoes it straight back from the request, and DOM-based when the page’s own JavaScript writes it into the page, for example with innerHTML.

Cross-site request forgery (CSRF) abuses the fact that browsers attach cookies automatically. While you are logged in to a shop, a page on another site submits a hidden form to the shop’s change-email address, and a shop that checks only the cookie obeys. The main defence is an anti-CSRF token in each form that changes data, checked by the server; SameSite cookies are a second layer, not a replacement. Lax still sends cookies when the user follows a link from another site, one reason data must never change through a GET request.

• Enter ' " < > & and <b>qa</b> in text fields, then look everywhere the value appears later: lists, admin screens, e-mails, exports. Expected: the characters as typed, never bold text, and Arabic or emoji input still intact.
• Error pages stay generic: no stack trace, SQL or file path. An apostrophe that causes a database error suggests text glued into a query; report it and do not probe further.
• Forms that change data carry a hidden token or send one in a header, and nothing is deleted, paid or changed through a plain link.
• With permission, replay such a request without its token, for example copied as cURL with the token removed. Expected: the server refuses it.

Try it: HTML Entity Encoder

Security headers

Security headers are response headers that switch on protections in the browser. They are a second layer that limits the damage of a defect such as XSS; they do not fix it. Check the main HTML pages in the Network panel or paste their headers into the Security Header Analyzer, and read each value, not just its presence.

• Content-Security-Policy (CSP) lists where scripts, styles, images and frames may load from. default-src 'self' allows only the page’s own origin (same scheme, host and port) and blocks inline scripts; 'unsafe-inline' for scripts lets an injected inline script run, and a * source lets one load from any site.
• frame-ancestors in the CSP, or the older X-Frame-Options: DENY, stops other sites from framing the page to trick users into clicking hidden buttons (clickjacking).
• X-Content-Type-Options: nosniff stops the browser from guessing file types, so a file served as text is not run as a script.
• Referrer-Policy limits how much of the URL other sites receive; Permissions-Policy switches off features the site does not use, such as the camera.
• Headers such as Server: nginx/1.18.0 or X-Powered-By reveal the software, often with its version, and tell attackers which known flaws to try: remove them or make them generic.

Try it: Security Header Analyzer Try it: HTTP Headers Parser

Worked example: a safe check of a profile page

A shop’s test plan includes a security smoke check of its new profile page, with the scope confirmed in writing by the security lead: the test environment, two test accounts, harmless inputs only. The tester works with the browser and DevTools.

http://test.shop.example/profile ends in a 301 redirect to HTTPS, and the page’s response headers are shown below. The Application panel shows the session cookie sid with Secure and SameSite=Lax but without HttpOnly. The display name Sara <b>QA</b> appears as typed on the profile page, but bold in the admin customer list. An apostrophe in the order search returns a 500 page with a database error. The profile form sends a hidden csrf_token, while Delete address is a plain link to /profile/address/delete?id=12. At the first sign of each weakness the tester stops probing it, saves the evidence and moves on to the next check.

The report lists the findings most serious first: the markup in the admin list (probable stored XSS, running in an administrator’s session), the database error, the GET delete link, the missing HttpOnly, the missing CSP and frame protection and, as a low-severity note, the nginx version.

GET /profile HTTP/1.1
Host: test.shop.example

HTTP/1.1 200 OK
Server: nginx/1.18.0
Content-Type: text/html; charset=utf-8
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

Frequently asked questions

References

• OWASP Web Security Testing Guide (WSTG)OWASP FoundationThe reference methodology for testing web applications and APIs for security weaknesses, test by test.
• OWASP Cheat Sheet Series: Cross Site Scripting PreventionOWASP FoundationPreventing XSS: output encoding for each context, sanitizing user-authored HTML, safe DOM sinks and framework protections, with CSP only as defence in depth.
• OWASP Cheat Sheet Series: Cross-Site Request Forgery PreventionOWASP FoundationCSRF defences: synchronizer tokens, SameSite cookies and origin checks.
• OWASP Cheat Sheet Series: HTTP HeadersOWASP FoundationWhich security headers to send (HSTS, CSP, X-Content-Type-Options, frame protection) and which to remove (Server, X-Powered-By).