SE Notes
Testing software systems for vulnerabilities and security weaknesses.
Security testing is the systematic process of evaluating a software system's ability to protect data, maintain functionality, and resist unauthorized access or malicious attacks. Unlike functional testing that verifies what the system does, security testing verifies what the system prevents—ensuring that access controls cannot be bypassed, data cannot be stolen, and the system cannot be manipulated into unintended behavior. In an era where data breaches cost organizations an average of $4.45 million and regulatory penalties for security failures can reach billions, security testing is not optional—it is a fundamental quality requirement.
Types of Security Testing
Vulnerability Scanning uses automated tools to identify known security weaknesses in the system. Scanners check for outdated software versions with known vulnerabilities, misconfigured services, default credentials, open ports, and common security misconfigurations. Tools like Nessus, OpenVAS, and Qualys can scan infrastructure and applications quickly but may produce false positives and cannot find business logic vulnerabilities.
Penetration Testing (Pen Testing) simulates real-world attacks by skilled security professionals who attempt to exploit vulnerabilities to gain unauthorized access. Unlike automated scanning, penetration testers think creatively, chain multiple minor weaknesses into significant exploits, and test business logic. A penetration test might discover that while the login page resists brute force attacks, an API endpoint for password reset does not rate-limit requests.
Static Application Security Testing (SAST) analyzes source code without executing it to identify security flaws. SAST tools examine code for patterns known to create vulnerabilities—SQL injection risks, buffer overflows, insecure cryptographic usage, and hardcoded credentials. Tools like SonarQube, Checkmarx, and Fortify integrate into CI/CD pipelines to catch vulnerabilities before code reaches production.
Dynamic Application Security Testing (DAST) tests the running application by sending crafted requests and analyzing responses. DAST tools like OWASP ZAP and Burp Suite probe the application from the outside, attempting SQL injection, cross-site scripting, and other attacks against the live system.
Interactive Application Security Testing (IAST) combines SAST and DAST approaches by instrumenting the application during testing to observe both the input (requests) and the internal behavior (code execution paths). This reduces false positives while maintaining the breadth of analysis.
Security Testing Process
| Threat Modeling | Test Planning → Tool Configuration → Execution |
| Vulnerability Discovery | Risk Assessment → Reporting → Remediation |
| Verification (Re-test) | Documentation → Continuous Monitoring |
Threat Modeling identifies what assets need protection, who might attack them, and how. Using frameworks like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege), the team systematically identifies potential threats that security testing should target.
Test Planning defines scope (which systems, features, and attack surfaces to test), approach (black-box, white-box, or grey-box), timeline, and acceptance criteria (what severity of vulnerabilities is acceptable for release).
Real-World Example: Healthcare Portal Security Testing
A patient portal handling protected health information undergoes comprehensive security testing:
Vulnerability Scan Results:
- Two servers running Apache 2.4.49 with known path traversal vulnerability (CVE-2021-41773)—Critical
- Admin interface accessible from public internet without VPN—High
- TLS 1.0 still enabled alongside TLS 1.2—Medium
SAST Findings:
- SQL injection vulnerability in patient search function where input is concatenated directly into queries—Critical
- Hardcoded API key for email service found in source code—High
- Session tokens generated using predictable random number generator—High
Penetration Test Discoveries:
- Broken access control: By modifying patient ID in URL, one patient can view another patient's medical records—Critical
- Session does not invalidate after password change, allowing compromised sessions to persist—High
- Rate limiting absent on login endpoint, enabling brute force attacks—Medium
- Verbose error messages reveal database structure to attackers—Low
Remediation:
- Parameterized queries replace string concatenation
- Access control checks verify the requesting user owns the requested resource
- Servers upgraded to patched Apache version
- Session management redesigned with proper invalidation
- Rate limiting implemented with exponential backoff
Common Security Test Cases
Authentication Testing:
- Attempt login with SQL injection payloads in username/password fields
- Test password reset flow for account enumeration (different responses for valid vs. invalid emails)
- Verify multi-factor authentication cannot be bypassed
- Test session timeout and concurrent session handling
Authorization Testing:
- Attempt to access resources belonging to other users by modifying IDs
- Test horizontal privilege escalation (user A accessing user B's data)
- Test vertical privilege escalation (regular user accessing admin functions)
- Verify API endpoints enforce the same access controls as the UI
Input Validation Testing:
- Submit XSS payloads in every input field and verify they are not reflected or stored
- Attempt SQL injection in search fields, login forms, and API parameters
- Test file upload for executable file inclusion and path traversal
- Submit oversized inputs to test buffer handling
Cryptography Testing:
- Verify passwords are hashed with strong algorithms (bcrypt, Argon2)
- Confirm sensitive data is encrypted in transit (TLS) and at rest
- Check that encryption keys are not stored alongside encrypted data
- Test that deprecated algorithms (MD5, SHA1, DES) are not used
Security Testing in CI/CD Pipelines
Modern development practices integrate security testing into automated pipelines:
- Pre-commit hooks: Check for hardcoded secrets before code is committed
- Build phase: SAST tools scan code for vulnerability patterns
- Test phase: DAST tools test the deployed test environment
- Dependency check: Tools like Snyk or Dependabot flag vulnerable dependencies
- Infrastructure scanning: Terraform/CloudFormation configurations checked for security misconfigurations
- Post-deployment: Continuous monitoring detects anomalous behavior in production
Challenges in Security Testing
Testing for the absence of vulnerabilities is inherently harder than testing for the presence of features. Attackers only need to find one weakness; defenders must protect against all possible attacks. Security testing requires specialized expertise that many development teams lack. The threat landscape continuously evolves, meaning yesterday's secure system may be vulnerable to tomorrow's attack techniques. False positives from automated tools can overwhelm teams, while false negatives provide dangerous false confidence. Organizations must balance security testing thoroughness against development velocity and time-to-market pressures.
Exam Focus
Revise definitions, diagrams, examples, and short-answer points for Security Testing.
Interview Use
Prepare one clear explanation, one practical example, and one common mistake for this Software Engineering topic.
Search Terms
software-engineering, software engineering, software, engineering, security, testing, security testing
Related Software Engineering Topics