Cybersecurity and Pentesting - Fundamentals

This handbook is about understanding risk and safely testing systems you are authorized to assess. It does not replace a professional security audit, but it helps with vulnerability classes, threat modeling and interpreting basic security-tool output.

Related topics: Web Application Security, Linux Permissions and Server Security, OAuth 2.0, OpenID Connect, JWT and Sessions and HTTP, HTTPS and TLS.

1. Goal

This handbook is for developers and people responsible for digital solutions.

The goal is not to become a professional pentester, but to understand:

• security fundamentals,
• common attack classes,
• attacker mindset,
• testing your own systems,
• basic security tools,
• defensive best practices.

Perform security testing only on systems you are authorized to test.

2. CIA triad

Confidentiality

Data is visible only to authorized parties.

Integrity

Data is not modified without authorization.

Availability

Systems remain accessible when needed.

3. Threat modeling

Before securing a system, ask:

• what are we protecting?
• from whom?
• what attack paths exist?
• what would the impact be?
• what controls already exist?

Example:

system:
admin panel

assets:
customer data

threat:
administrator account takeover

vectors:
brute force
phishing
session theft

controls:
MFA
rate limiting
HTTPS
session expiry

4. Attack surface

Attack surface includes everything that can potentially be abused:

• exposed ports,
• APIs,
• forms,
• admin panels,
• accounts,
• file uploads,
• dependencies,
• external services.

Expose less where possible.

5. Least privilege

Every user and process should have only the permissions it needs.

This applies to operating systems, databases, APIs, containers, CI/CD and cloud accounts.

6. Defense in depth

Do not rely on one security layer.

firewall
+ SSH keys
+ MFA
+ updates
+ monitoring
+ backups

7. Authentication and authorization

Authentication:

who are you?

Authorization:

what are you allowed to do?

They are different problems.

8. Passwords

Good practices:

• unique passwords,
• long passwords/passphrases,
• password manager,
• MFA,
• no sharing.

Servers should never store plaintext passwords.

Use established password hashing such as Argon2id, bcrypt or scrypt.

9. MFA

MFA significantly reduces account takeover risk.

Examples:

• TOTP,
• hardware security keys,
• passkeys.

10. Updates

Many real attacks exploit known, old vulnerabilities.

Keep operating systems, libraries, Docker images, web servers, CMS software and firmware updated.

11. Backups

Backups are part of cybersecurity.

A useful baseline:

• automated,
• off the primary server,
• versioned/rotated,
• tested.

12. Encryption

At rest:

disk
database
backup

In transit:

TLS / HTTPS
SSH
VPN

13. OWASP Top 10

The OWASP Top 10:2025 highlights broken access control, security misconfiguration, software supply chain failures, cryptographic failures, injection, insecure design, authentication failures, software or data integrity failures, security logging and alerting failures, and mishandling of exceptional conditions.

Understanding the failure mode matters more than memorising names.

14. SQL Injection

Use prepared statements and parameterised queries. Validate input, but do not rely on validation alone.

15. XSS

An attacker tries to run JavaScript in another user's browser context.

Defences include output escaping, safe templating, Content Security Policy and avoiding unsafe DOM APIs such as untrusted innerHTML.

16. CSRF

CSRF abuses the authenticated browser session.

Typical protections include CSRF tokens, SameSite cookies and appropriate API design.

17. SSRF

An attacker tries to make the backend request an unauthorized destination.

Defences include allowlists, network restrictions and careful address validation.

18. Broken access control

For a resource such as:

/user/123/invoice/99

the backend must verify that the current user is authorized to access invoice 99.

19. Security headers

Useful headers include:

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

20. Security testing methodology

A useful high-level flow:

recon
 ↓
enumeration
 ↓
analysis
 ↓
validation
 ↓
report
 ↓
fix
 ↓
retest

21. Reconnaissance

In an authorized test, reconnaissance means learning what the system exposes.

Questions include:

• which domains exist?
• which services are exposed?
• which technologies are used?
• which server versions are visible?

22. Nmap

Use Nmap on systems you are authorized to test.

nmap 192.168.56.10
nmap -sV 192.168.56.10
sudo nmap -O 192.168.56.10

It can identify ports, services and sometimes operating system characteristics.

23. Nikto

Nikto scans web servers for common issues.

nikto -h http://192.168.56.10

Treat scanner output as leads, not automatic proof of vulnerability.

24. OWASP ZAP

ZAP is a web proxy and security scanner.

It can intercept requests, inspect headers and test applications for common problems.

It is a useful tool for developers testing their own web applications.

25. Burp Suite

Burp Suite is a standard web-security testing toolkit.

Important concepts include proxying, modifying requests, replaying requests and observing responses.

A valuable learning loop is:

intercept request
modify it
send again
observe response

26. BeEF

The Browser Exploitation Framework is mainly useful in isolated training labs to demonstrate the impact of browser-side code execution.

The developer takeaway is that XSS can lead to serious session and browser-context abuse.

27. Metasploit

Metasploit is a framework for researching and validating known vulnerabilities in authorized environments.

A developer should understand the concepts of exploit, payload, module and session.

28. Wireshark

Wireshark analyses network traffic including TCP, UDP, DNS, TLS and other protocols.

It is also useful for troubleshooting.

29. tcpdump

sudo tcpdump -i any
sudo tcpdump -i any port 443
sudo tcpdump -i any host 192.168.1.20

30. Gobuster / ffuf

Directory/resource enumeration tools can help find forgotten endpoints in a controlled lab.

The defensive lesson is simple:

• hidden URLs are not access control,
• remove obsolete endpoints,
• protect every resource with real authorization.

31. curl

One of the most useful security tools for developers:

curl -I https://example.com
curl -v https://example.com
curl -H 'X-Test: 1' https://example.com

32. OpenSSL

Inspect TLS:

openssl s_client -connect example.com:443 -servername example.com

This lets you inspect certificates, chain and handshake details.

33. testssl.sh

Useful for checking your own TLS configuration, supported protocols, cipher suites and certificate issues.

34. Lynis

Unix/Linux security auditing:

sudo lynis audit system

It provides hardening recommendations.

35. Trivy

Trivy can scan Docker images, filesystems, dependencies and infrastructure-as-code.

trivy image myapp:latest

36. Dependency scanning

Node:

npm audit

Go:

govulncheck ./...

Python:

pip-audit

37. Secret scanning

Repositories should be checked for accidental API keys, tokens, passwords and private keys.

Common tools include Gitleaks and TruffleHog.

38. SAST

Static Application Security Testing analyses source code without running it.

Examples include Semgrep, CodeQL and SonarQube.

39. DAST

Dynamic Application Security Testing examines a running application.

Examples include OWASP ZAP, Burp Scanner and Nikto.

40. SCA

Software Composition Analysis checks dependencies and known vulnerabilities.

Examples include Dependabot, Renovate, Trivy and Snyk.

41. CVE and CVSS

CVE identifies a known vulnerability.

CVSS estimates potential severity.

A high CVSS score does not automatically mean your application is exploitable. Configuration, exposure, version and usage matter.

42. Pentest vs vulnerability scan

A vulnerability scan is primarily automated discovery of known issues.

A penetration test combines manual analysis, validation and risk assessment.

Scanners do not replace skilled human testing.

43. Training lab

Use intentionally vulnerable applications such as:

• OWASP Juice Shop,
• WebGoat,
• DVWA,
• Metasploitable.

Keep them isolated.

44. Example lab

VirtualBox / KVM
      |
      +-- Kali / Debian tools
      |
      +-- OWASP Juice Shop
      |
      +-- DVWA

Use host-only or internal networking and do not expose deliberately vulnerable machines publicly.

45. Kali Linux

Kali is Debian with a preinstalled security-tool set.

It is not magic. A normal Debian installation with selected tools is also perfectly suitable for learning.

46. Basic workflow for testing your own application

1. inspect exposed ports,
2. inspect TLS,
3. inspect HTTP headers,
4. proxy the application through ZAP/Burp,
5. verify authentication and authorization,
6. review input handling,
7. scan dependencies,
8. scan Docker images,
9. inspect logs,
10. write down findings.

47. Pentest report

A useful finding includes:

vulnerability name
description
impact
preconditions
evidence
risk
recommendation
fix status

48. Severity

Common labels:

Critical
High
Medium
Low
Informational

Assess real impact rather than copying a scanner score blindly.

49. Retest

fix
 ↓
retest

A fix is not complete until it has been verified.

50. Logging and monitoring

Security also means detecting incidents.

Log failed logins, permission changes, authentication errors, suspicious requests and administrative events.

51. Incident response - minimum

If compromise is suspected:

1. preserve logs,
2. restrict access,
3. rotate secrets,
4. determine scope,
5. remove the root cause,
6. restore from a trusted source if needed,
7. monitor closely.

52. Developer best practices

• HTTPS everywhere,
• parameterised SQL,
• secure cookies,
• secrets outside repositories,
• regular updates,
• dependency scanning,
• least privilege,
• no publicly exposed database unless required,
• firewalling,
• backups,
• health checks,
• monitoring,
• code review.

53. Minimal toolset

Developer:

curl
nmap
OWASP ZAP or Burp
Trivy
govulncheck / npm audit / pip-audit
Gitleaks
Wireshark or tcpdump
openssl

Training lab:

Burp Suite
OWASP ZAP
Nmap
Nikto
ffuf / Gobuster
Metasploit
BeEF
Wireshark

54. What not to do

Do not test systems, production services, company infrastructure or random public IP addresses without authorization.

Even “just scanning” may be treated as unwanted activity.

55. Security mindset

Cybersecurity is not mainly about “hacking”.

Ask:

What can go wrong?
How could someone abuse it?
How will I detect it?
How can I limit the impact?
How quickly can I recover?

56. What you should know

You should understand common vulnerability classes, attack surface, basic pentest methodology, the roles of tools such as Nmap/ZAP/Burp, how to build an isolated lab, how to test your own applications, how to scan dependencies and images, how to read a pentest report and how to apply basic hardening and monitoring.

Official references

• OWASP Top 10:2025: https://top10.owasp.org/2025/
• OWASP Web Security Testing Guide: https://owasp.org/www-project-web-security-testing-guide/
• OWASP Cheat Sheet Series: https://cheatsheetseries.owasp.org/