A checklist for scanning your own site safely

Before you point any scanner at production, take 10 minutes to set up the guardrails. Here is what actually matters.

Scanning is not risk-free

A security scanner fires thousands of requests with unusual payloads. Even "safe" payloads can:

• Trigger your WAF or Cloudflare rate limits, blocking legitimate users mid-scan
• Fill your database with junk records from form-submission tests
• Email your support team from contact form fuzzing
• Send SMS or email notifications if the app has notification hooks
• Generate huge logs that fill disk
• Trip fraud-detection systems that pause payouts

None of this is irreversible, but cleaning up afterward is more work than preventing the mess up front.

The 10-minute prep checklist

1. Take a database backup

Full dump, right now, before you scan. If the scanner triggers a form that you thought was safe but actually writes to a table, you will want to roll back rather than clean up manually.

2. Warn anyone who monitors the site

Support team, co-founders, ops contractor. A one-line Slack message ("running a security scan on the main site for the next 2 hours, ignore alerts") prevents a panicked incident response.

3. Whitelist your scanner IP

In Cloudflare or your WAF, add a bypass rule for your scanner's source IP. This serves two goals:

• You are testing your app's security, not your WAF's
• You avoid getting IP-banned mid-scan

If you want to test with the WAF enabled (to validate your WAF config), do that in a second scan pass.

4. Pick a maintenance window

Weekends at 3am in your target user's timezone. If anything goes wrong, fewer users are affected and you have time to fix before peak hours.

5. Start with the Quick profile

Resist the urge to go straight to a full pentest scan. Quick profile first (10 pages, depth 2) tells you whether the site can handle the load at all. If the quick scan crashes your app, the deep scan would have been catastrophic. Scale up only after the quick pass completes cleanly.

6. Watch CPU and memory during the scan

On cPanel or whatever hosting dashboard you have, keep the resource graph open. If CPU pegs at 100% or memory trends up and never comes back, pause and investigate — that is often a backend bug the scan triggered.

7. Know what payloads are genuinely dangerous

Web Iron Shield ships with safe defaults (echo, sleep, SELECT-only SQL, static XSS canaries), but some scanners do not. If you use other tools, check what they do in "aggressive" modes. Common risks:

• SQLi scanners that try UPDATE/DELETE injection
• XSS scanners that send JavaScript that actually executes (breaks UI, can submit forms)
• Brute-forcers that hit login endpoints rapidly and lock accounts

8. Have a rollback plan

If you see something weird (db corrupt, emails being sent, errors in production logs), what is your emergency stop?

• Stop the scanner: know the keyboard shortcut or kill signal
• Roll back the DB: have the backup file path written down somewhere you will remember under stress
• Flush malicious records: if you know the scanner's User-Agent, you can DELETE FROM table WHERE user_agent = 'WebIronShield%'

9. Document the authorization

Even scanning your own site: write down "I, [you], authorized this scan on [date]" somewhere durable. If an incident response team or your hosting provider ever asks, you will be glad you did. Web Iron Shield logs this automatically to scan_audit.log.

10. Plan for false positives

Your first scan will flag things that are not real bugs. That is normal. Use Verify Now on each finding — confirmed vulnerabilities get actioned immediately, Inconclusive findings go to the "investigate later" list. Do not panic-fix everything.

After the scan

Things to do in the hour after the scan completes:

1. Check production logs for unusual errors timestamped during the scan window
2. Look at your database for junk records (sort by created_at DESC on users and contacts tables)
3. Verify the email queue is not backed up with triggered notifications
4. Export the scan findings to your tracker (JSON or CSV export from the History menu)
5. Rate the findings: Critical → fix today, High → fix this week, Medium → fix this sprint, Low → backlog

When NOT to scan production

Some situations call for a staging-only scan:

• You have never scanned this app before (start in staging)
• The app has integrations with third parties that charge per API call
• The app has real-money flows (payments, payouts)
• You are doing a deep or pentest profile (start with quick on prod, deep on staging)