Web Application Security

01Purpose and scope

• This manual supports the course Web Application Security. It is written for developers, testers, architects and product owners who build or maintain sites, APIs and single page applications that accept input from users or other systems.
• The manual covers the full life of an application, from early design through release and daily operation. It concentrates on the flaws that cause most real incidents in web software, including broken access control, injection, weak authentication and session handling, cryptographic failures, insecure design and security misconfiguration. Network hardening, endpoint management and physical security are outside scope except where they change how the application should behave.
• Guidance here does not replace qualified professional judgment, approved procedures or required authorization. Testing a system you do not own without written permission is illegal in many places, and rules on personal data, breach notification and payment card handling vary by jurisdiction and sector. Check the current authoritative source for your region and your organization's policy before acting on any rule described here.

02Core principles

• Deny by default. Every request, role and data path should be refused unless a specific rule allows it. Teams that start from an allow list and add exceptions with a reason tend to find fewer access control defects than teams that start open and try to close gaps later.
• Enforce controls on the server. Browser checks, hidden form fields and client-side routing rules improve the user experience, but they do not protect anything. Authorization decisions, input validation for business rules and rate limits belong in code that the user cannot modify.
• Validate input at trust boundaries and encode output for its destination. Input from a browser, a partner API, a file upload or a message queue all cross a boundary. The right encoding depends on where the value lands: an HTML body, an attribute, a JavaScript string, a SQL statement or a shell command each need a different treatment.
• Use layers rather than a single gatekeeper. A web application firewall, a parameterized query, a strict content security policy and a least privilege database account each reduce risk on their own. None of them should be the only thing standing between an attacker and the data.
• Make security decisions visible. Record why a risk was accepted, who approved it and when it will be reviewed. Hidden exceptions are where most long-lived vulnerabilities come from.
• Accept trade-offs with open eyes. Strong session timeouts, step-up authentication and strict input rules add friction for users and effort for developers. Every control should be justified against the harm it prevents and the cost it adds.

03Planning and preparation

• Start with an inventory. List the pages, endpoints, user roles, data classes, third-party scripts, external services and open source components the application uses. Mark which data is personal, financial, health related or credential material, because those classes drive most later decisions. An inventory that is out of date by a few weeks is still far more useful than none.
• Run a threat model before feature work is locked. A common approach uses STRIDE, which prompts the team to consider spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege for each element in a data flow diagram. The output should be a diagram, a list of threats with an owner for each, and a set of decisions on which threats will be mitigated, transferred or accepted.
• Define the scope and rules for testing before anyone sends traffic to a live or shared environment. Write down which hosts are in scope, which accounts may be used, what volume of requests is acceptable, whether denial of service testing is excluded, and who to call if something breaks. Get written authorization from the system owner. Keep the record with the test report.
• Adjust preparation to context. An internal reporting tool used by twenty staff on a private network needs a lighter program than a public storefront that processes card payments. A consumer application that stores health information carries obligations that a marketing site does not. Be explicit about the data and exposure that set the level of effort, and say what you are not covering so that gaps are visible to decision makers.
• Agree on the verification standard early. The OWASP Application Security Verification Standard provides levels of requirements that organizations can select according to the sensitivity of the application. Choosing a level before design keeps later debates about what counts as enough grounded in something written down.

04Recommended workflow

1. 1
   : Convert the threat model into security requirements. Each high or medium threat should map to at least one requirement the team can build and test, such as a rule that every object lookup checks the requesting user's rights to that object.
2. 2
   : Design authentication, session handling and authorization before writing feature code. Decide where session tokens are stored, how long they live, how they are rotated after login and how privilege changes are handled. Document the authorization model as a table of roles and actions, and identify which checks run in middleware and which must run inside each handler.
3. 3
   : Implement with safe defaults. Use parameterized queries or an object relational mapper that binds parameters. Rely on the template engine's automatic escaping and avoid building HTML by string concatenation. Set cookies with the Secure, HttpOnly and SameSite attributes, add anti forgery protection for state changing requests, and send headers such as a content security policy and frame restrictions. Pin dependency versions and record where each library came from.
4. 4
   : Run automated checks on every change. Static analysis finds some injection and unsafe API patterns. Software composition analysis flags known vulnerable libraries. Secret scanning catches keys committed to a repository. Unit and integration tests should cover authorization rules, especially negative cases where a user tries to reach another user's record. Treat tool output as a list of leads, since most tools produce both misses and false alarms.
5. 5
   : Perform dynamic testing in a staging environment that resembles production. Run an authenticated scan with a tool such as an intercepting proxy or a scanner configured with test accounts for each role. Then test by hand. Automated tools rarely understand business logic, such as whether a discount can be applied twice or whether an order can be modified after payment.
6. 6
   : Triage and fix findings. Rate each finding by impact and how easily it can be exploited in your environment, not by a generic score alone. Assign an owner, set a target date based on severity, implement the fix, and retest the exact steps that produced the finding. Close the item only after the retest passes and the fix is merged.
7. 7
   : Release with a configuration review and watch the results. Confirm that debug modes are off, error pages are generic, administrative interfaces are not exposed, storage buckets are not public and logging captures security relevant events without recording passwords or full card numbers. Once live, monitor authentication failures, unusual request volumes and privilege changes, and rehearse the steps for revoking sessions and rotating secrets.

05Quality checks, risk controls and compliance

• Quality in this field means that known defect classes are prevented, found early and tracked to closure. Useful checks include whether every state changing endpoint has an authorization test, whether user input reaches sensitive sinks only through approved helper functions, and whether the team can explain how each high severity finding was introduced and how the change process would now catch it. Peer review of security relevant code, such as authentication, payment flows and file handling, adds a second reader for the parts where mistakes are costly.
• Risk controls should match the threat. Rate limiting and account lockout reduce credential stuffing, but they can also lock out legitimate users, so thresholds need tuning with support staff. A web application firewall can block common attack patterns and buy time for a fix, yet it cannot repair a broken authorization check and it often produces false positives on legitimate input. Treat it as a compensating control with a documented review date, not as a substitute for code correction.
• Compliance adds obligations that depend on where the users and the organization are located. Privacy statutes may require notice, minimization, access requests and breach reporting within set deadlines. If the application handles payment card data, the Payment Card Industry Data Security Standard sets specific requirements that apply to the whole cardholder data environment. Sector rules for health, finance and education add their own demands. Confirm the current requirements with your compliance or legal team and the official text of each rule, since these requirements change over time.
• In regulated or high risk settings, this guidance is a starting point only. Decisions about data retention, breach response, acceptable risk and testing authorization belong to qualified professionals and to the people formally assigned those responsibilities in your organization. Follow the approved procedures for your environment even where this manual suggests something different.

06Collaboration and documentation

• Security work in web applications spreads across roles. Product owners decide which data is collected and how much friction users will accept. Developers write the controls and their tests. Testers verify behavior from the outside. Operations staff manage certificates, configuration, logging and incident response. A security engineer or champion usually coordinates threat models, reviews high risk changes and maintains the testing toolchain. Name each role for each application so that no finding falls between teams.
• Documentation should be short enough that people read it and specific enough that it is useful during an incident. Keep four artifacts current: the data flow diagram with its trust boundaries, the threat list with owners and status, decision records for significant choices such as token storage or third party identity providers, and an exception register. Each exception should state the risk, the compensating controls, the approver and an expiry date that forces review.
• Findings need to be written so a developer can act on them without a meeting. A good report gives the affected component, the exact request or steps that reproduce the issue, what an attacker could do, the evidence collected and a suggested fix with a reference to the relevant coding guidance. Avoid copying raw scanner output into tickets. Reviewers should be able to repeat the test themselves, and a retest should be recorded against the same ticket.

07Measures and continuous improvement

• Choose indicators that reveal the health of the practice rather than the volume of activity. Useful ones include the number of open high severity findings and their age, the share of changes that pass automated security checks before merge, the time between a finding being reported and its verified fix, the number of authorization defects found after release, and the count of exceptions past their review date. Set your own baselines from your data. Comparing your numbers to outside figures is unreliable unless the definitions match exactly.
• Use each incident and near miss to improve the process. After a serious finding or breach, hold a blameless review that asks how the flaw passed design review, testing and deployment, and which control would have caught it earliest. Turn the answer into a new test, a checklist item, a library helper or a training example. Small changes made after each event usually do more than large programs launched once a year.
• Refresh the threat model when the application changes in a meaningful way, such as adding a payment provider, a public API, a new role or a file upload feature. Review the tool configuration periodically so that scanners still exercise the current frameworks and that rule sets have not drifted. Tools and standards evolve, so schedule time for the team to read the current guidance rather than relying on memory.

08Common mistakes and how to prevent them

• Checking permissions only in the user interface. Hiding a button does not stop a request. Every handler that reads or changes a record should check the caller's rights to that specific record, and tests should send requests as a user who should be refused.
• Trusting identifiers supplied by the client. Numeric IDs in URLs make it easy to try neighboring values. Look up each object through the user's permitted scope, for example by querying orders where the owner matches the session user, rather than fetching by ID and checking afterward.
• Validating only in the browser. Scripts, proxies and direct API calls bypass any client check. Repeat validation on the server for every field that matters, and treat business rules such as price, quantity and discount as values the server computes.
• Building SQL, shell commands or HTML by joining strings. Prevent this with parameterized queries, safe APIs and automatic escaping. Add a lint rule or code review checklist item to flag concatenation near sensitive sinks.
• Leaking detail in errors and logs. Stack traces, database messages and internal paths help attackers. Return generic messages to users, record full detail in protected logs, and scrub passwords, tokens and card data before anything is written.
• Storing secrets in source code or client bundles. Keep credentials in a managed secret store, rotate them on a schedule and on suspicion of exposure, and run secret scanning on every commit.
• Relying on a scanner to say the application is secure. Automated tools miss logic flaws and produce noise. Pair them with targeted manual testing of the highest risk flows: login, password reset, payment, file upload and administrative actions.
• Forgetting third party code. Scripts loaded from outside domains, old libraries and unused plugins all expand the attack surface. Inventory them, pin versions, use subresource integrity where supported, and remove what is no longer needed.

09Practical checklist

• Confirm written authorization and rules of engagement exist for every test that touches a live or shared system.
• Maintain a current inventory of endpoints, roles, data classes, integrations and third party components.
• Complete a threat model with a data flow diagram, and assign an owner to each threat that is not fully mitigated.
• Record the verification level chosen for the application and the reason for that choice.
• Enforce authorization on the server for every read and write, and include negative tests for other users' records.
• Use parameterized queries, automatic output encoding and anti forgery protection on state changing requests.
• Set session cookies with Secure, HttpOnly and SameSite attributes and define session lifetime and rotation rules.
• Run static analysis, dependency checks and secret scanning on every change before merge.
• Perform authenticated dynamic testing and manual review of login, payment, upload and administrative flows before release.
• Review production configuration for debug settings, exposed admin interfaces, public storage and verbose errors.
• Verify that logs capture security events and exclude passwords, tokens and full card numbers.
• Track exceptions with an approver, a compensating control and an expiry date.
• Confirm privacy, payment and sector obligations with the current authoritative source and the responsible compliance owner.
• Review the threat model and tool configuration after significant changes and after any incident.

★Learning sources

• Micro Degree: Web Application Security
• Micro Degree: Data Analytics Applications
• Micro Degree: Azure Cloud Fundamentals
• Micro Degree: Google Cloud Platform Basics