Cyber Security /Web Security Fundamentals / Lesson
Cyber Security

Security Testing Concepts

Learn the fundamentals of security testing, including static analysis, dynamic testing, vulnerability scanning, manual review, penetration testing and responsible security validation.

🎯

Learning Objectives

["Understand the purpose of security testing.","Explain the difference between verification and security validation.","Understand static application security testing.","Understand dynamic application security testing.","Understand software composition and dependency scanning.","Understand manual security review.","Understand penetration testing at a conceptual level.","Understand vulnerability scanning and its limitations.","Understand test planning, scope and authorization.","Document and communicate security findings responsibly."]

📖

Lesson Content

Security Testing Concepts

Security testing is the process of evaluating an application, system or
configuration to identify security weaknesses before attackers can exploit
them.

Security testing should be performed with clear authorization, defined scope
and appropriate safety controls.

1. Why Security Testing Matters

Developers can make mistakes even when following secure development practices.
Testing provides another opportunity to identify weaknesses.

Security testing should complement secure design and development rather than
replace them.

2. Verification and Validation

Verification asks whether security requirements and controls have been
implemented correctly.

Validation asks whether the resulting application actually behaves securely
under realistic conditions.

3. Static Application Security Testing

Static Application Security Testing, or SAST, examines source code or compiled
representations without necessarily executing the application.

SAST can identify patterns associated with insecure coding practices.

4. Dynamic Application Security Testing

Dynamic Application Security Testing, or DAST, evaluates a running application.

It can identify weaknesses that become visible through the application’s
external behaviour.

5. Software Composition Analysis

Modern applications depend heavily on third-party libraries.
Software Composition Analysis, or SCA, helps identify dependencies and known
security vulnerabilities.

6. Vulnerability Scanning

Vulnerability scanners automatically examine systems for known weaknesses.

Automated scanning is useful but not perfect. Scanners can produce false
positives and may miss vulnerabilities requiring business or application
context.

7. Manual Security Review

Manual review allows security professionals to examine application behaviour,
business logic and implementation details that automated tools may not fully
understand.

8. Penetration Testing

Penetration testing is an authorized security assessment designed to identify
and demonstrate exploitable weaknesses within a defined scope.

A professional penetration test requires explicit authorization and carefully
defined rules of engagement.

9. Rules of Engagement

Rules of engagement define what testers are allowed to assess and how testing
should be performed.

They may specify:

  • Target systems.
  • Testing dates.
  • Allowed techniques.
  • Excluded systems.
  • Emergency contacts.
  • Evidence handling.
  • Reporting requirements.

10. Scope

Scope identifies exactly what is included in the assessment.

A tester should never assume that a system is authorized simply because it is
technically reachable.

11. Vulnerability vs Risk

A vulnerability is a weakness. Risk considers the likelihood and impact
associated with that weakness.

A technically serious vulnerability may have different practical risk levels
depending on the affected asset and environment.

12. False Positives

A false positive occurs when a tool reports a suspected vulnerability that is
not actually present.

Security professionals should validate important findings before reporting
them as confirmed vulnerabilities.

13. False Negatives

A false negative occurs when a testing process fails to identify a vulnerability
that exists.

No single testing technique can identify every possible weakness.

14. Test Evidence

Security findings should be supported with appropriate evidence.

Evidence may include safe reproduction steps, affected endpoints, sanitized
screenshots, logs or code references.

Evidence must be handled carefully so that sensitive information is not
unnecessarily exposed.

15. Security Testing Lifecycle

  1. Obtain authorization.
  2. Define scope.
  3. Understand the target.
  4. Identify attack surfaces.
  5. Perform appropriate testing.
  6. Validate findings.
  7. Assess risk.
  8. Document evidence.
  9. Report findings.
  10. Retest remediation.

16. Secure Testing in Development

Security checks can be integrated into development pipelines.

  • Code scanning.
  • Dependency scanning.
  • Secret scanning.
  • Unit security tests.
  • Integration testing.
  • Dynamic testing.

17. Security Testing in CI/CD

Automated security checks can run whenever code changes are submitted.
This can help detect vulnerabilities before software reaches production.

Security tools should be configured carefully to reduce unnecessary noise and
ensure that important findings receive attention.

18. Manual Business Logic Testing

Some vulnerabilities depend on how an application is intended to work.
Business logic weaknesses may therefore require human reasoning.

Examples include incorrect approval workflows, bypassed payment steps,
unauthorized role changes and workflow manipulation.

19. Reporting Security Findings

A useful security finding should explain:

  • What was discovered.
  • Where it was discovered.
  • Why it matters.
  • How it can be reproduced safely.
  • What the potential impact is.
  • How it should be remediated.

20. Retesting

After remediation, the security team should retest the affected area to
confirm that the vulnerability has been properly addressed.

21. Security Testing Ethics

Security testing without authorization can cause data loss, service disruption
or legal consequences.

Always obtain explicit authorization before conducting security testing.

22. Practical Authorized Lab

Create a small local web application and perform a basic defensive security
review.

Document the application’s attack surface, authentication controls, input
validation, authorization logic, dependencies and security configuration.

Identify weaknesses and propose fixes without targeting external systems.

23. Common Security Testing Mistakes

  • Testing systems without authorization.
  • Ignoring scope.
  • Trusting automated scanner results without validation.
  • Failing to document evidence.
  • Exposing sensitive test data.
  • Ignoring business logic.
  • Failing to retest fixes.
  • Confusing vulnerabilities with risk.
  • Failing to communicate findings clearly.

24. Knowledge Check

  1. What is security testing?
  2. What is SAST?
  3. What is DAST?
  4. What is software composition analysis?
  5. What is penetration testing?
  6. Why is authorization important?
  7. What is a false positive?
  8. What is a false negative?
  9. Why is manual business-logic testing important?
  10. Why should vulnerabilities be retested after remediation?

25. Summary

Security testing provides an important layer of assurance in the software
development lifecycle. Different techniques identify different classes of
weaknesses, so effective security programs combine automated tools, manual
review, secure development practices and authorized testing.


Security testing should always be authorized, scoped, documented and performed
responsibly.

💻

Code Example

<?php

/*
 * Simple defensive example:
 * validate expected input before processing it.
 */

$username = isset( $_POST['username'] )
	? trim( (string) $_POST['username'] )
	: '';

if ( $username === '' ) {
	die( 'Username is required.' );
}

if ( strlen( $username ) > 100 ) {
	die( 'Username is too long.' );
}

/*
 * Continue with server-side authorization,
 * secure database access and output encoding.
 */
⭐

Key Takeaways

["Security testing identifies weaknesses before attackers exploit them.","Testing must be authorized and properly scoped.","SAST examines application code.","DAST examines running applications.","SCA identifies vulnerable dependencies.","Automated scanners can produce false positives and false negatives.","Manual review is important for business logic.","Penetration testing requires explicit authorization.","Security findings should contain evidence and remediation guidance.","Retesting confirms whether vulnerabilities were fixed."]

Enjoying this lesson?

Sign in to your Dwallnet Academy student account to track your learning progress and mark lessons as complete.

Sign In to Track Progress