Web Security Fundamentals

Web Security Fundamentals

Web security is the practice of protecting websites, web applications, their
users, data and supporting infrastructure from unauthorized access, misuse,
disruption and other security risks.

Modern organizations depend heavily on web applications for communication,
commerce, education, banking, government services and internal operations.
Because these applications often process sensitive information, web security
is an important part of cybersecurity.

1. What Is Web Security?

Web security involves the technologies, processes, design principles and
security controls used to protect web-based systems.

Web security aims to protect:

• User accounts
• Passwords and authentication credentials
• Personal information
• Financial information
• Business information
• Application functionality
• Servers and databases
• Communication between clients and servers

The goal is not simply to prevent hacking. A secure web application should also
protect confidentiality, integrity and availability.

2. The CIA Triad in Web Security

The three traditional information-security objectives are:

3. How a Web Application Works

A typical web application involves several components.

1. User browser
2. Web server
3. Application code
4. Database
5. External services or APIs

For example, when a student logs into an LMS, the browser sends a request to
the web server. The application processes the request, communicates with the
database and returns an appropriate response.

Every component introduces potential security considerations.

4. Client and Server

A web browser normally acts as the client, while a web server or application
server processes requests and returns responses.

Examples of client applications include:

• Google Chrome
• Mozilla Firefox
• Microsoft Edge
• Safari

A server may run software such as Apache, Nginx, PHP, Node.js or another
application platform.

The browser should never be treated as a trusted environment. Data received
from the browser must be validated on the server.

5. HTTP

HTTP stands for Hypertext Transfer Protocol.
It is one of the main protocols used for communication between web clients and
servers.

A basic HTTP request can contain:

• HTTP method
• URL/path
• Headers
• Cookies
• Request body

Common HTTP methods include:

• GET
• POST
• PUT
• PATCH
• DELETE

The exact behavior of these methods depends on the application and API design.

6. HTTPS

HTTPS is HTTP transmitted through TLS.
It helps protect data while it travels between the client and server.

HTTPS provides important protections including:

• Encryption of network traffic
• Integrity protection
• Server authentication through certificates

HTTPS is essential for modern websites, especially applications handling
authentication or sensitive information.

However, HTTPS does not automatically make an application secure. An application
can still contain vulnerabilities while using HTTPS.

7. TLS Certificates

TLS certificates help a browser verify the identity associated with a website
during a secure TLS connection.

A valid certificate does not guarantee that the website itself is trustworthy
or free from vulnerabilities. It primarily supports secure communication and
server identity verification.

8. Authentication

Authentication answers the question:

“Who are you?”

Common authentication methods include:

• Passwords
• Multi-factor authentication
• Security keys
• One-time codes
• Biometric authentication

Strong authentication reduces the likelihood that unauthorized users can access
accounts.

Authentication is covered in greater detail in Module 5 Lesson 2.

9. Authorization

Authorization answers the question:

“What are you allowed to do?”

For example, a student may be allowed to view course lessons while an administrator
may be allowed to create or edit lessons.

Authentication and authorization are different concepts.
A user can be successfully authenticated but still not have permission to access
a particular resource.

Authorization is covered in greater detail in Lesson 3.

10. Input Validation

Input validation ensures that information supplied to an application meets the
expected format, type, range and business rules.

Examples include:

• Checking that an email address has an expected structure.
• Ensuring a quantity is numeric.
• Restricting an identifier to an approved format.
• Limiting the length of text fields.
• Rejecting unexpected values.

Validation should be performed on the server because client-side validation can
be bypassed.

11. Output Encoding

Input validation and output encoding solve different problems.

Output encoding converts data into a form that is safe for its destination
context.

For example, when displaying user-supplied text in HTML, applications should
escape the output appropriately.

In PHP, a common example is:

<?php

echo htmlspecialchars(
    $username,
    ENT_QUOTES,
    'UTF-8'
);

This helps prevent user-controlled text from being interpreted as HTML markup
in the output context.

12. Secure Password Storage

Applications should never store user passwords as plain text.

Modern password storage should use dedicated password-hashing functions such
as PHP’s password_hash().

<?php

$password = 'Example-password';

$hash = password_hash(
    $password,
    PASSWORD_DEFAULT
);

echo htmlspecialchars(
    $hash,
    ENT_QUOTES,
    'UTF-8'
);

Passwords should be verified using password_verify() rather than
being manually compared with stored hashes.

13. Session Security

Web applications commonly use sessions to remember that a user has authenticated.

A secure session design should consider:

• Secure session identifiers
• Session expiration
• Logout behavior
• Session renewal after authentication
• Secure cookie settings
• Protection against session theft

Cookies containing authentication-related session information should use
appropriate security attributes such as Secure,
HttpOnly and an appropriate SameSite setting.

14. Common Web Application Vulnerabilities

Web applications can contain many types of vulnerabilities.
Important categories include:

• Injection vulnerabilities
• Cross-site scripting (XSS)
• Broken access control
• Authentication weaknesses
• Security misconfiguration
• Insecure cryptographic practices
• Unsafe file handling
• Server-side request issues
• Insecure deserialization
• Vulnerable or outdated components

Understanding these categories helps developers recognize security problems
before applications are deployed.

15. SQL Injection

SQL injection can occur when untrusted input is incorporated into SQL statements
without appropriate parameterization.

A defensive approach is to use prepared statements.

For example, WordPress developers can use:

<?php

global $wpdb;

$user_id = 10;

$row = $wpdb->get_row(
    $wpdb->prepare(
        "SELECT * FROM {$wpdb->users}
         WHERE ID = %d",
        $user_id
    )
);

The example demonstrates parameterization rather than constructing SQL by
concatenating untrusted input.

16. Cross-Site Scripting

Cross-site scripting, commonly called XSS, occurs when untrusted content is
handled in a way that allows unintended script execution in a user’s browser.

Common defensive measures include:

• Context-appropriate output encoding
• Input validation
• Content Security Policy
• Safe templating practices
• Appropriate cookie protections

The correct defense depends on where the data is inserted and how the browser
interprets that context.

17. Broken Access Control

Broken access control occurs when an application does not correctly enforce
what authenticated users are permitted to access or modify.

For example, an application should not assume that because a user can change
an ID in a URL, the user is automatically authorized to access the corresponding
record.

Authorization must be checked on the server.

18. Cross-Site Request Forgery

Cross-Site Request Forgery, or CSRF, involves causing an authenticated browser
to send an unwanted request to a web application.

Defensive measures can include:

• CSRF tokens
• Appropriate SameSite cookie settings
• Origin or Referer validation where appropriate
• Re-authentication for sensitive operations

WordPress developers commonly use nonces as part of request protection.

19. Security Headers

HTTP response headers can provide additional security controls.

Examples include:

• Content-Security-Policy
• X-Content-Type-Options
• Referrer-Policy
• Strict-Transport-Security
• Permissions-Policy

Security headers should be configured according to the requirements of the
application. They are not a replacement for secure application code.

20. Secure File Uploads

File-upload functionality requires careful security design.

Applications should consider:

• Allowed file types
• File size limits
• Content validation
• Filename handling
• Storage location
• Execution permissions
• Access control
• Malware scanning where appropriate

Never assume that a file is safe merely because its filename has a familiar
extension.

21. Secure Development Principles

Security should be considered throughout the software-development lifecycle,
not added only after an application has been completed.

Important principles include:

• Least privilege
• Defense in depth
• Secure defaults
• Fail securely
• Complete mediation
• Minimize attack surface
• Separation of duties
• Keep security simple
• Never trust client-side input

22. Least Privilege

Least privilege means users, applications and services should receive only the
permissions required for their legitimate responsibilities.

For example, a web application that only needs to read certain information
should not automatically receive unrestricted administrative access to the
entire database.

23. Defense in Depth

Defense in depth uses multiple security controls so that failure of one control
does not automatically result in complete compromise.

A web application may use:

• HTTPS
• Strong authentication
• Authorization checks
• Input validation
• Output encoding
• Database parameterization
• Security headers
• Logging
• Monitoring
• Backups

24. Secure Defaults

A secure application should be safe by default.

Examples include:

• New accounts should not automatically receive administrative privileges.
• Debug information should not be exposed in production.
• Unused features should be disabled where practical.
• Default passwords should not remain active.

25. Error Handling

Error messages should help legitimate users without exposing unnecessary internal
information.

For example, a production application should avoid displaying database passwords,
full filesystem paths, stack traces or internal configuration details to ordinary
users.

Detailed information should instead be recorded securely in appropriate logs.

26. Logging and Monitoring

Security logs can help detect and investigate suspicious activity.

Useful events may include:

• Successful logins
• Failed login attempts
• Password changes
• Privilege changes
• Administrative actions
• Unexpected errors
• File-upload events
• Important configuration changes

Logs should be protected from unauthorized modification and should avoid
unnecessary exposure of sensitive information.

27. Dependency Security

Modern web applications frequently depend on external libraries and frameworks.
Outdated dependencies can contain known vulnerabilities.

Developers should:

• Maintain a software inventory.
• Track dependency versions.
• Apply appropriate security updates.
• Remove unused dependencies.
• Review dependency sources.

28. Secure Configuration

Security depends not only on code but also on system configuration.

Important areas include:

• Web-server configuration
• PHP configuration
• Database permissions
• File permissions
• TLS configuration
• Application settings
• Debug settings

Development and production environments should be configured appropriately for
their different purposes.

29. Security Testing

Security testing is the process of evaluating an application to identify
security weaknesses.

Common categories include:

• Code review
• Static application security testing (SAST)
• Dynamic application security testing (DAST)
• Dependency scanning
• Configuration review
• Vulnerability scanning
• Authorized penetration testing

Security testing should always be performed within an approved scope.

30. Static Application Security Testing

SAST analyzes source code or compiled representations to identify potential
security problems without necessarily executing the application.

Examples of findings may include:

• Unsafe functions
• Potential injection paths
• Weak cryptographic usage
• Hard-coded secrets
• Unsafe data handling

31. Dynamic Application Security Testing

DAST evaluates an application while it is running.

It can help identify issues that are observable through the application’s
external behavior.

Testing should be performed against systems where the tester has explicit
authorization.

32. Vulnerability Scanning

Vulnerability scanners can identify known weaknesses in systems and applications.

Scanner results should be reviewed carefully because automated tools can produce
false positives and false negatives.

A security professional should validate important findings before deciding on
remediation.

33. Penetration Testing

Authorized penetration testing simulates selected attack techniques to determine
whether security controls can resist them.

A professional penetration test should have:

• Written authorization
• Defined scope
• Testing windows
• Rules of engagement
• Emergency contacts
• Data-handling requirements
• Reporting procedures

Students should never test websites or applications without permission.

34. Security Testing in the Development Lifecycle

Security testing is more effective when performed throughout development.

A simplified lifecycle can be:

1. Security requirements
2. Threat modeling
3. Secure design
4. Secure coding
5. Code review
6. Automated testing
7. Security testing
8. Remediation
9. Deployment
10. Monitoring

35. Threat Modeling

Threat modeling is a structured way of thinking about how a system could be
misused or attacked.

Developers can ask:

• What assets need protection?
• Who are the legitimate users?
• What trust boundaries exist?
• What could go wrong?
• What security controls reduce the risks?

36. Web Security and WordPress

WordPress developers should apply the same fundamental security principles to
themes, plugins and custom applications.

Important practices include:

• Use capability checks.
• Use nonces for appropriate state-changing requests.
• Sanitize input according to context.
• Escape output according to context.
• Use prepared SQL statements.
• Validate uploaded files.
• Keep WordPress and plugins updated.
• Avoid unnecessary administrative privileges.

37. Example — Secure WordPress Capability Check

<?php

if ( ! current_user_can( 'manage_options' ) ) {

    wp_die(
        esc_html__(
            'You are not authorized to perform this action.',
            'dwallnet'
        )
    );
}

echo 'Authorized administrator.';

This demonstrates the principle that an authenticated user should not automatically
be considered authorized to perform every action.

38. Example — Safe Input Validation

<?php

$email = 'student@example.com';

if ( filter_var( $email, FILTER_VALIDATE_EMAIL ) ) {

    echo 'Valid email format.';

} else {

    echo 'Invalid email format.';
}

Validation should reflect the actual requirements of the application rather than
assuming that one validation rule is appropriate for every situation.

39. Web Security Testing Lab

Create a small web application inside an authorized local development environment.

Review the application for:

1. Authentication controls.
2. Authorization checks.
3. Input validation.
4. Output encoding.
5. Password storage.
6. Session handling.
7. CSRF protection.
8. Database query safety.
9. Error handling.
10. Security headers.

Do not perform testing against third-party websites or systems without explicit
authorization.

40. Security Review Checklist

41. Common Web Security Mistakes

• Trusting browser-side validation.
• Assuming authentication means authorization.
• Storing passwords in plain text.
• Building SQL queries by concatenating untrusted input.
• Displaying unescaped user input.
• Using insecure session settings.
• Exposing detailed production errors.
• Giving users unnecessary privileges.
• Leaving outdated dependencies installed.
• Testing production systems without authorization.

42. Security by Design

The most effective security approach is to consider security before the application
is built rather than waiting until after deployment.

Security requirements should be part of system design, database design,
authentication architecture, API design, coding standards and testing procedures.

43. Review Questions

1. What is web security?
2. What are confidentiality, integrity and availability?
3. What is the difference between authentication and authorization?
4. Why should server-side validation be used?
5. What is output encoding?
6. Why should passwords never be stored as plain text?
7. What is a session?
8. What is XSS?
9. What is SQL injection?
10. What is CSRF?
11. What is broken access control?
12. What is defense in depth?
13. What is least privilege?
14. What is SAST?
15. What is DAST?
16. Why must security testing have an authorized scope?

44. Key Takeaways

• Web security protects applications, users, data and supporting infrastructure.
• Confidentiality, integrity and availability are foundational security objectives.
• HTTPS protects communication but does not eliminate application vulnerabilities.
• Authentication determines identity while authorization determines permitted actions.
• Server-side input validation is essential.
• Output should be encoded according to its destination context.
• Passwords should be stored using appropriate password-hashing mechanisms.
• Session management requires secure identifiers, cookies and lifecycle controls.
• Prepared statements help prevent SQL injection.
• Secure development should use least privilege and defense in depth.
• Security testing should be integrated into the development lifecycle.
• Security testing must be performed only within an authorized scope.

45. Conclusion

Web security is a combination of secure architecture, secure coding, appropriate
configuration, strong authentication and authorization, careful data handling,
monitoring and continuous security testing.

A cybersecurity professional should understand that no single security control
can protect every web application. Effective security comes from combining
multiple defensive practices throughout the application’s lifecycle.

Next Lesson: Module 5, Lesson 2 — Authentication.