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/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'll want to rollback 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 arabicfood.co.za 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're testing your app's security, not your WAF's
- You avoid getting IP-banned mid-scan
If you want to test with 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've been catastrophic. Scale up only after quick completes cleanly.
6. Watch CPU and memory during the scan
On cPanel / 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's 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 don't. 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's 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'll 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'll 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 aren't real bugs. That's normal. Use Verify Now on each finding — confirmed vulnerabilities get actioned immediately, Inconclusive findings go to the "investigate later" list. Don't panic-fix everything.
After the scan
Things to do in the hour after the scan completes:
- Check production logs for unusual errors timestamped during the scan window
- Look at your database for junk records (sort by created_at DESC on users/contacts tables)
- Verify email queue isn't backed up with triggered notifications
- Export the scan findings to your tracker (JSON or CSV export from the History menu)
- 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've 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're doing deep / pentest profile (start with quick on prod, deep on staging)