Practical Web & Email Security Assessment Guide

📊 View Presentation Slides

TestSSL, Nikto, WPScan, Clickjacking, SPF and DKIM

1. Introduction

A web application is protected by several different security layers.

At the network and transport layer, we have TLS/SSL.

At the web-server layer, we have technologies such as Apache, Nginx, IIS, application frameworks, HTTP headers, and server configuration.

At the application layer, we may have WordPress, plugins, themes, APIs, authentication systems, and business logic.

Finally, email infrastructure has its own security controls, including:

• ›SPF
• ›DKIM
• ›DMARC

This guide focuses on six important security assessments:

These are complementary tests. One tool cannot identify everything.

For example:

TestSSL
   ↓
Transport Security

Nikto
   ↓
Web Server Security

WPScan
   ↓
WordPress Security

Clickjacking
   ↓
Browser/UI Security

SPF
   ↓
Email Infrastructure Authorization

DKIM
   ↓
Email Cryptographic Authentication

2. Legal and Ethical Testing

Before running security scanners against a real website, you need authorization.

A safe environment can be created using:

• ›Your own virtual machine
• ›A local web server
• ›A deliberately vulnerable application
• ›An organization-approved penetration-testing environment
• ›A CTF/lab environment

Do not scan random public websites simply because they are accessible.

A useful lab architecture is:

┌──────────────────────┐
│ Kali Linux           │
│                      │
│ TestSSL              │
│ Nikto                │
│ WPScan               │
│ curl / dig           │
└──────────┬───────────┘
           │
           │ Authorized testing
           ▼
┌──────────────────────┐
│ Vulnerable Lab       │
│                      │
│ Web Server           │
│ WordPress            │
│ Test Applications    │
└──────────────────────┘

3. TestSSL

3.1 What is TLS?

TLS stands for:

Transport Layer Security

TLS protects communication between a client and server.

When you visit:

https://example.com

the browser establishes a TLS connection with the server.

The simplified process is:

Browser
   |
   | TLS ClientHello
   ↓
Server
   |
   | ServerHello + Certificate
   ↓
Browser
   |
   | Certificate validation
   ↓
Cryptographic key establishment
   ↓
Encrypted HTTPS communication

TLS provides three important properties:

Confidentiality

An attacker should not be able to read the encrypted traffic.

Integrity

An attacker should not be able to silently modify the traffic.

Authentication

The certificate helps the browser verify that it is communicating with the intended server.

3.2 Why TLS Configuration Matters

Having HTTPS enabled does not automatically mean the configuration is secure.

For example, a server could theoretically support:

TLS 1.0
TLS 1.1
TLS 1.2
TLS 1.3

Modern systems generally prefer:

TLS 1.2
TLS 1.3

Similarly, a server could have a valid certificate but still support undesirable cipher suites.

Therefore, security testing should examine:

• ›Protocol versions
• ›Cipher suites
• ›Certificate
• ›Key exchange
• ›Forward secrecy
• ›Known TLS vulnerabilities
• ›Configuration problems

3.3 Installing TestSSL

Clone the project:

git clone --depth 1 https://github.com/drwetter/testssl.sh.git

Enter the directory:

cd testssl.sh

Check the help menu:

./testssl.sh --help

3.4 Basic Scan

For an authorized HTTPS target:

./testssl.sh example.com

You can also specify HTTPS explicitly:

./testssl.sh https://example.com

The tool performs a broad TLS assessment.

3.5 Testing Protocols

Run:

./testssl.sh --protocols example.com

You may see results indicating:

TLS 1.0
TLS 1.1
TLS 1.2
TLS 1.3

The important question is not merely:

SECURITY_ADVISORY

"Does the server support TLS?"

Instead ask:

SECURITY_ADVISORY

"Which TLS versions does it support, and are any obsolete versions enabled?"

3.6 Why TLS 1.0/1.1 Matter

Old TLS versions are deprecated because modern security standards have moved toward stronger cryptographic protocols.

If a server supports obsolete protocols, the organization's security policy may require them to be disabled.

However, severity should be determined according to:

• ›Application requirements
• ›Supported clients
• ›Organizational policy
• ›Regulatory requirements
• ›Actual cryptographic exposure

Do not automatically classify every legacy protocol finding as Critical.

3.7 Cipher Suites

A cipher suite describes the cryptographic algorithms used by TLS.

A simplified example could include:

Key exchange
+
Authentication
+
Encryption
+
Integrity

Run:

./testssl.sh --ciphers example.com

You should look for:

• ›Weak algorithms
• ›Deprecated ciphers
• ›NULL encryption
• ›Export-grade cryptography
• ›Insecure configurations
• ›Lack of forward secrecy where required

3.8 Certificate Testing

Run:

./testssl.sh --certificate example.com

Check:

Expiration

Is the certificate still valid?

Subject

Does it correspond to the intended domain?

SAN

Subject Alternative Name should contain the appropriate DNS names.

Issuer

Who issued the certificate?

Signature algorithm

Is the certificate using a modern cryptographic signature?

Key size

Is the key sufficiently strong?

Certificate chain

Is the chain correctly configured?

3.9 Vulnerability Scan

You can run:

./testssl.sh --vulnerable example.com

This checks for various known TLS weaknesses.

Remember:

A scanner finding is not automatically a confirmed exploitable vulnerability.

Always validate important findings.

3.10 TestSSL Finding Example

Suppose the scanner reports:

TLS 1.0 offered

Your report could contain:

Title

Deprecated TLS Protocol Supported

Description

The server supports an obsolete TLS protocol that is no longer recommended for modern secure communication.

Steps to Reproduce

./testssl.sh --protocols target.example

Evidence

TLS 1.0 offered

Recommendation

Disable deprecated TLS protocols and retain supported modern TLS versions based on organizational compatibility requirements.

4. Nikto

4.1 What is Nikto?

Nikto is a web-server security scanner.

It performs checks against HTTP/HTTPS servers for potentially interesting security issues.

Nikto can identify things such as:

• ›Dangerous files
• ›Default files
• ›Exposed directories
• ›Server configuration problems
• ›Missing security headers
• ›Outdated server components
• ›Known web-server issues
• ›Interesting HTTP responses

4.2 Nikto vs TestSSL

These tools operate at different layers.

TestSSL

Primarily:

Client
 ↓
TLS
 ↓
HTTPS server

Nikto

Primarily:

HTTP request
 ↓
Web server
 ↓
Application

Therefore, both can be useful in the same assessment.

4.3 Installing Nikto

On Kali Linux:

sudo apt update
sudo apt install nikto

Verify:

nikto -Version

4.4 Basic Scan

Run:

nikto -h https://example.com

Nikto will make a series of HTTP requests and inspect responses.

4.5 Scanning HTTP

For port 80:

nikto -h example.com -p 80

For HTTPS:

nikto -h example.com -p 443

4.6 Saving Results

Text output:

nikto -h https://example.com -o nikto-report.txt

HTML:

nikto -h https://example.com -o nikto-report.html -Format htm

Saving results is useful because the output becomes evidence for your assessment.

4.7 Understanding Nikto Output

Imagine Nikto reports:

+ Server: Apache
+ The X-Frame-Options header is not present.
+ The X-Content-Type-Options header is not set.

This does not mean:

CRITICAL VULNERABILITY

Instead, it means:

SECURITY_ADVISORY

A security control may be missing.

You then perform manual validation.

For example:

curl -I https://example.com

Then inspect the headers.

4.8 Why False Positives Matter

Automated scanners don't understand the entire business context.

For example:

Missing security header

may be reported.

But perhaps:

• ›The application intentionally allows framing.
• ›A reverse proxy adds the header.
• ›Only a harmless static page is frameable.
• ›CSP provides equivalent protection.

Therefore:

Automated Finding
       ↓
Manual Verification
       ↓
Context Analysis
       ↓
Confirmed Finding

4.9 Nikto Example Report

Title

Missing X-Content-Type-Options Header

Description

The HTTP response does not include the X-Content-Type-Options header.

Reproduction

curl -I https://target.example

Inspect the response.

Recommendation

Where appropriate, configure:

X-Content-Type-Options: nosniff

Then retest the application.

5. WPScan

5.1 What is WordPress?

WordPress is a popular content-management system.

A typical WordPress installation consists of:

WordPress Core
      +
Themes
      +
Plugins
      +
Web Server
      +
Database

Security problems can occur in any of these components.

5.2 What is WPScan?

WPScan is designed specifically for WordPress security testing.

It can identify:

• ›WordPress version
• ›Plugins
• ›Themes
• ›Users
• ›Potentially vulnerable components
• ›Configuration information
• ›Known vulnerabilities

5.3 Installing WPScan

On Kali:

sudo apt update
sudo apt install wpscan

Check:

wpscan --version

5.4 Basic Scan

wpscan --url https://wordpress.example

The scanner attempts to identify WordPress characteristics.

5.5 Plugin Enumeration

wpscan --url https://wordpress.example --enumerate p

The p option is used for plugin enumeration.

The scanner may identify something such as:

Plugin: example-plugin
Version: 1.2.0

5.6 Theme Enumeration

wpscan --url https://wordpress.example --enumerate t

This attempts to identify themes.

5.7 User Enumeration

For an authorized test:

wpscan --url https://wordpress.example --enumerate u

If usernames are exposed, you might see:

admin
editor
author

The security significance depends on how the application handles authentication and account enumeration.

5.8 Why Plugin Versions Matter

Suppose WPScan identifies:

Plugin:
Example Plugin

Version:
1.2.0

You should not immediately write:

SECURITY_ADVISORY

"The plugin is vulnerable."

Instead, determine:

Installed version
       ↓
Affected version range
       ↓
Known vulnerability
       ↓
Fixed version
       ↓
Actual applicability

For example:

Installed: 1.2.0
Affected: <= 1.2.3
Fixed: 1.2.4

Then the finding is much stronger.

5.9 WPScan API

WPScan can use its vulnerability database with an API token.

Example:

wpscan --url https://wordpress.example --api-token YOUR_API_TOKEN

Never publish your real token.

Do not put it in:

• ›GitHub
• ›Screenshots
• ›Public reports
• ›Blog posts
• ›Shared shell history

5.10 WPScan Example Finding

Title

Outdated WordPress Plugin

Description

The WordPress installation contains a plugin version associated with a known security vulnerability.

Reproduction

wpscan --url https://target.example --enumerate p

Evidence

Plugin: example-plugin
Version: 1.2.0

Validation

Compare the installed version with the affected version range from a trusted vulnerability source.

Recommendation

Upgrade to a supported fixed version.

If the plugin is unnecessary:

Remove the plugin completely.

6. Clickjacking

6.1 What is Clickjacking?

Clickjacking is an attack technique where an attacker causes a victim to interact with a legitimate application through a deceptive interface.

The victim believes they are clicking one thing, but the underlying framed application receives the interaction.

A simplified concept:

Attacker page
┌───────────────────────────┐
│ Fake interface            │
│                           │
│       CLICK HERE          │
│           ↓               │
│   ┌───────────────────┐   │
│   │ Target website    │   │
│   │ inside iframe     │   │
│   └───────────────────┘   │
└───────────────────────────┘

The practical impact depends heavily on the functionality exposed by the target application.

6.2 Why Clickjacking Works

Browsers support frames and iframes.

For example:

<iframe src="https://example.com"></iframe>

If the target application allows itself to be framed, another page may potentially embed it.

Therefore, applications can tell browsers:

SECURITY_ADVISORY

"Do not allow my pages to be displayed inside frames except under these conditions."

6.3 X-Frame-Options

One traditional protection is:

X-Frame-Options: DENY

This means:

Do not allow this page to be framed.

Another option is:

X-Frame-Options: SAMEORIGIN

This allows framing by the same origin.

6.4 Content-Security-Policy

Modern applications can use CSP.

For example:

Content-Security-Policy: frame-ancestors 'none';

This means the page cannot be framed.

Another example:

Content-Security-Policy: frame-ancestors 'self';

This allows framing by the same origin.

6.5 Checking a Website

Run:

curl -I https://target.example

Look for:

X-Frame-Options:

and:

Content-Security-Policy:

If CSP exists, inspect whether it contains:

frame-ancestors

6.6 Safe Clickjacking Lab

Create a deliberately vulnerable local page:

<!DOCTYPE html>
<html>
<head>
    <title>Clickjacking Lab</title>
</head>

<body>

<h1>Account Settings</h1>

<button>Change Setting</button>

</body>
</html>

Run it using a local server:

python3 -m http.server 8000

Now create another HTML page:

<!DOCTYPE html>
<html>
<head>
    <title>Frame Test</title>
</head>

<body>

<h1>Frame Test</h1>

<iframe
    src="http://localhost:8000"
    width="1000"
    height="600">
</iframe>

</body>
</html>

Run the second page:

python3 -m http.server 9000

Open:

http://localhost:9000

If the first application loads inside the iframe, it is frameable.

6.7 Important Point

Frameable does not automatically equal exploitable clickjacking.

You need to determine whether the framed application contains a sensitive action that could realistically be triggered through deceptive UI interaction.

For example:

Public informational page
        ↓
Frameable
        ↓
Low security significance

versus:

Authenticated account page
        ↓
Frameable
        ↓
Sensitive action
        ↓
Potential clickjacking impact

The second scenario is much more important.

6.8 Remediation

A common protection is:

Content-Security-Policy: frame-ancestors 'none';

or, if the application requires same-origin framing:

Content-Security-Policy: frame-ancestors 'self';

Use the policy that matches the application's legitimate requirements.

7. SPF

7.1 What is SPF?

SPF means:

Sender Policy Framework

SPF is an email authentication mechanism.

It tells receiving mail servers which servers are authorized to send email for a domain.

For example:

example.com

could publish:

v=spf1 ip4:203.0.113.10 -all

This conceptually means:

203.0.113.10
       ↓
Authorized sender

Everything else
       ↓
SPF failure

7.2 Why SPF Matters

Without appropriate email authentication, attackers may have an easier time impersonating a domain in certain email-delivery scenarios.

SPF allows receiving systems to ask:

SECURITY_ADVISORY

"Is this sending server authorized to send mail for this domain?"

7.3 Finding SPF

Use:

dig TXT example.com +short

Or:

nslookup -type=TXT example.com

Look for:

v=spf1

Example:

"v=spf1 include:_spf.example.com -all"

7.4 SPF Components

An SPF record can contain several mechanisms.

ip4

ip4:203.0.113.10

Authorizes an IPv4 address/range.

ip6

ip6:2001:db8::/32

Authorizes an IPv6 range.

include

include:_spf.provider.example

Allows another domain's SPF policy to contribute authorization.

a

a

Uses addresses associated with the domain's A/AAAA records.

mx

mx

Uses mail-exchange hosts.

all

Controls the result for everything not previously matched.

7.5 SPF Qualifiers

Common qualifiers include:

+all
-all
~all
?all

They represent different policy outcomes.

The most permissive is:

+all

because it effectively authorizes all senders.

A commonly seen restrictive ending is:

-all

which indicates unauthorized senders should fail SPF.

7.6 Multiple SPF Records

One important configuration problem is having multiple independent SPF policies.

For example:

v=spf1 include:provider1.example -all

and another:

v=spf1 include:provider2.example -all

Instead of publishing separate SPF records, the authorized services generally need to be combined into a single SPF policy.

7.7 SPF Lookup Limit

SPF evaluation has a DNS lookup limit.

Complex policies containing many nested:

include:
a
mx
redirect

mechanisms can run into this limit.

This is an important reason not to keep adding providers blindly to an SPF record.

7.8 SPF Reproduction

Run:

dig TXT example.com +short

Then inspect:

v=spf1

Questions to ask:

1. Is SPF present?

2. Is there exactly one SPF policy?

3. Are only legitimate sending services authorized?

4. Is +all present?

5. Is the policy unnecessarily broad?

6. Could DNS lookup limits become a problem?

7. Are obsolete mail providers still included?

7.9 SPF Report Example

Finding

SPF Policy Missing

Description

No SPF record was identified for the domain.

Reproduction

dig TXT example.com +short

No TXT record beginning with:

v=spf1

was identified.

Impact

The domain does not provide SPF authorization information to receiving mail systems.

Recommendation

Publish an SPF policy that identifies legitimate mail-sending infrastructure.

8. DKIM

8.1 What is DKIM?

DKIM means:

DomainKeys Identified Mail

Unlike SPF, DKIM uses cryptographic signatures.

The basic architecture is:

Mail Server
    |
    | Private key
    ↓
DKIM Signature
    |
    ↓
Email
    |
    ↓
Receiving Server
    |
    | Public key from DNS
    ↓
Signature verification

8.2 Private and Public Keys

The sending system holds the:

Private key

The DNS record contains the:

Public key

The private key should never be published.

The public key can be retrieved from DNS.

8.3 DKIM Selector

DKIM uses a selector.

An email header may contain something conceptually like:

d=example.com
s=selector1

The selector tells the receiving server where to find the public key.

The DNS lookup becomes:

selector1._domainkey.example.com

8.4 Querying DKIM

Run:

dig TXT selector1._domainkey.example.com

You might receive:

"v=DKIM1; k=rsa; p=PUBLIC_KEY"

Important values include:

v=DKIM1

DKIM version.

k=rsa

Key type.

p=...

Public key.

8.5 Finding the Selector

The easiest practical approach is to inspect a legitimate test email.

Look for:

DKIM-Signature:

Then identify:

d=

and:

s=

For example:

d=example.com;
s=selector1;

Then query:

dig TXT selector1._domainkey.example.com

8.6 Authentication Results

A receiving mail system may provide:

Authentication-Results:
    dkim=pass

This is important.

There is a difference between:

DKIM DNS record exists

and:

DKIM authentication successfully passed

The second is stronger validation.

8.7 DKIM Testing Workflow

Use this workflow:

Send authorized test email
          ↓
Receive the email
          ↓
Inspect headers
          ↓
Find DKIM-Signature
          ↓
Identify selector
          ↓
Query DNS
          ↓
Find public key
          ↓
Check Authentication-Results
          ↓
Confirm dkim=pass

8.8 DKIM Report Example

Finding

DKIM Not Configured

Description

A DKIM public key could not be identified for the tested email-sending selector.

Reproduction

Identify the selector from the DKIM header:

s=selector1

Then query:

dig TXT selector1._domainkey.example.com

Recommendation

Configure DKIM through the organization's mail provider and publish the provider-generated public key under the appropriate selector.

9. SPF vs DKIM

These two technologies are often confused.

SPF

SPF primarily answers:

SECURITY_ADVISORY

"Is this server authorized to send mail for the domain?"

Conceptually:

Sending IP
     ↓
SPF policy
     ↓
Authorized?

DKIM

DKIM answers:

SECURITY_ADVISORY

"Does this email contain a valid cryptographic signature associated with the signing domain?"

Conceptually:

Email
 ↓
DKIM signature
 ↓
Public key
 ↓
Signature verification

10. Why DMARC Should Also Be Checked

Although this guide focuses on SPF and DKIM, professional email-security assessments should also examine:

DMARC

DMARC means:

Domain-based Message Authentication, Reporting, and Conformance

Check it with:

dig TXT _dmarc.example.com +short

A DMARC record may look like:

v=DMARC1; p=none;

or:

v=DMARC1; p=quarantine;

or:

v=DMARC1; p=reject;

DMARC uses SPF and DKIM results and adds domain-alignment and policy controls.

The simplified relationship is:

              Email
                |
       ┌────────┴────────┐
       ↓                 ↓
      SPF               DKIM
       |                 |
       └────────┬────────┘
                ↓
              DMARC
                ↓
       Domain-level policy

11. Complete Testing Methodology

Now combine everything into one workflow.

Phase 1 – Reconnaissance

Identify:

Domain
IP
Ports
Web server
Technologies
WordPress
Email infrastructure

Phase 2 – TLS Assessment

Run:

./testssl.sh target.example

Then:

./testssl.sh --protocols target.example

And:

./testssl.sh --ciphers target.example

Record:

TLS versions
Cipher suites
Certificate
Known issues

Phase 3 – Web Server Assessment

Run:

nikto -h https://target.example

Save:

nikto -h https://target.example -o nikto.txt

Manually validate important findings.

Phase 4 – WordPress Assessment

First confirm that the target is actually WordPress.

Then:

wpscan --url https://target.example

Enumerate plugins:

wpscan --url https://target.example --enumerate p

Enumerate themes:

wpscan --url https://target.example --enumerate t

Enumerate users only where authorized and appropriate:

wpscan --url https://target.example --enumerate u

Phase 5 – HTTP Security Headers

Run:

curl -I https://target.example

Review headers such as:

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

For clickjacking specifically, concentrate on:

X-Frame-Options

and:

Content-Security-Policy: frame-ancestors

Phase 6 – SPF

Run:

dig TXT target.example +short

Look for:

v=spf1

Analyze:

Authorized IPs
Includes
all mechanism
DNS lookup complexity
Multiple SPF records

Phase 7 – DKIM

Inspect a legitimate test email.

Find:

d=
s=

For example:

d=target.example
s=selector1

Then:

dig TXT selector1._domainkey.target.example

Finally verify:

dkim=pass

12. Severity Classification

Not every finding has the same severity.

A simple approach:

Informational

Provides useful information but does not represent a meaningful security weakness.

Example:

Server version disclosed

depending on context.

Low

Minor security-hardening issue.

Example:

Missing non-critical security header

Medium

Could contribute to a realistic attack or exposes meaningful security weakness.

Example:

Clickjacking on a sensitive authenticated page

High

Significant vulnerability that could lead to compromise or major data exposure.

Example:

Known vulnerable WordPress component with meaningful exploitation impact

Critical

Severe issue with potentially catastrophic impact.

Severity should always be based on the actual vulnerability and impact, not merely the tool's output.

13. Professional Finding Structure

For every confirmed finding, use this format:

Finding ID:
WEB-001

Title:
Missing Clickjacking Protection

Severity:
Medium

Affected Asset:
https://target.example

Description:
Explain the vulnerability.

Steps to Reproduce:
1.
2.
3.

Evidence:
Command/output/screenshot.

Impact:
Explain what an attacker could achieve.

Recommendation:
Explain how to fix it.

References:
Relevant security standards/vendor documentation.

Retest:
Explain how to verify remediation.

14. Example End-to-End Report

WEB-001 – Deprecated TLS Protocol

Severity: Medium

Tool: TestSSL

Affected Asset:

target.example:443

Reproduction:

./testssl.sh --protocols target.example

Evidence:

TLS 1.0 offered

Impact:

Supporting obsolete protocols may expose the service to legacy cryptographic weaknesses and violate modern security requirements.

Recommendation:

Disable deprecated protocols and retain supported TLS versions.

Retest:

Run the same TestSSL protocol check after remediation.

WEB-002 – Missing Clickjacking Protection

Severity: Low/Medium

Tool: curl / Manual Browser Test

Reproduction:

curl -I https://target.example

Inspect:

X-Frame-Options

and:

Content-Security-Policy

If appropriate protections are absent, perform controlled iframe testing.

Impact:

A frameable sensitive application page may potentially be abused in UI-redressing attacks.

Recommendation:

Implement an appropriate:

Content-Security-Policy: frame-ancestors 'none';

or another policy matching legitimate application requirements.

WEB-003 – Outdated WordPress Plugin

Severity: Dependent on vulnerability

Tool: WPScan

Reproduction:

wpscan --url https://target.example --enumerate p

Identify:

Plugin
Version

Validate the version against a trusted vulnerability database.

Impact:

Impact depends on the vulnerability associated with the installed version.

Recommendation:

Upgrade to a fixed supported version or remove the plugin.

MAIL-001 – SPF Configuration Issue

Severity: Dependent on configuration

Reproduction:

dig TXT target.example +short

Analyze:

v=spf1

Check authorization scope and the terminating all mechanism.

Recommendation:

Maintain a single, appropriately restrictive SPF policy containing only legitimate sending infrastructure.

MAIL-002 – DKIM Configuration Issue

Severity: Dependent on configuration

Reproduction:

Identify:

d=target.example
s=selector1

Then:

dig TXT selector1._domainkey.target.example

Verify the receiving server reports:

dkim=pass

Recommendation:

Configure DKIM correctly through the organization's mail provider and ensure the public key is published for the active selector.

15. Evidence Collection Checklist

During an assessment, maintain a directory such as:

security-assessment/
│
├── testssl/
│   ├── full-scan.txt
│   ├── protocols.txt
│   └── certificate.txt
│
├── nikto/
│   ├── scan.txt
│   └── scan.html
│
├── wpscan/
│   └── wordpress-scan.txt
│
├── clickjacking/
│   ├── headers.txt
│   └── screenshots/
│
├── email/
│   ├── spf.txt
│   ├── dkim.txt
│   └── headers/
│
└── report/
    └── final-report.pdf

This makes the assessment reproducible.

16. Important Difference: Scan vs Vulnerability

This is one of the most important concepts in penetration testing.

Suppose Nikto says:

Missing X-Frame-Options

That is a:

Scanner observation

not necessarily a:

Confirmed exploitable vulnerability

Similarly:

WPScan detected plugin

does not mean:

Plugin is vulnerable

And:

SPF exists

does not mean:

Email security is perfect

And:

DKIM DNS record exists

does not necessarily mean:

All outgoing mail passes DKIM

Professional security testing therefore follows:

Detection
   ↓
Validation
   ↓
Context
   ↓
Impact
   ↓
Severity
   ↓
Remediation
   ↓
Retest

17. Final Comparison

18. Final Takeaway

These six tests cover very different parts of an organization's attack surface.

                    INTERNET
                       |
          ┌────────────┴────────────┐
          ↓                         ↓
       WEB APP                    EMAIL
          |                         |
    ┌─────┼─────┐               ┌───┴───┐
    ↓     ↓     ↓               ↓       ↓
  TLS   Server  WordPress      SPF     DKIM
  |      |        |                    /
  |      |        |                   /
  └──────┴────────┘                DMARC
          |
      Browser
          |
     Clickjacking

TestSSL tells you whether the encrypted transport layer is properly configured.

Nikto helps identify common web-server and configuration weaknesses.

WPScan specializes in WordPress discovery and security assessment.

Clickjacking testing determines whether sensitive application pages can be framed and potentially abused through UI redressing.

SPF identifies authorized email-sending infrastructure.

DKIM provides cryptographic authentication for email.

Together, these tests provide a useful baseline security assessment, but they should not be considered a complete penetration test. A full web-application assessment should additionally cover authentication, authorization, session management, access control, input validation, injection vulnerabilities, file handling, API security, business logic, SSRF, XSS, CSRF, sensitive-data exposure, and dependency security.

The strongest assessment is one where every automated result is manually validated, supported by evidence, assigned an appropriate risk, remediated, and retested.