OWASP Top 10 Checklist for Marketing Website Developers

Every marketing site you launch across 40 locations is a public attack surface. Contact forms, booking widgets, and tracking tags sit on the open internet, and a single exposed form can leak lead data from every branch at once.

OWASP Top 10 is the industry-standard list of the most critical web application security risks. It matters now because every new location page, landing page, and vendor plugin adds another place a flaw can appear. Below, each risk maps to the work your developers do on marketing sites, with a pre-launch check for each.

What You'll Learn

• How each OWASP Top 10 category maps to concrete failure modes on marketing sites, CMS platforms, and headless builds
• Which access control and staging mistakes most often expose multi-location brands to unauthorized edits
• How to harden lead forms and booking widgets against injection, cross-site scripting, and bot abuse without hurting conversion rate
• How to audit third-party tags and dependencies so a single vendor script cannot compromise every page
• A patch cadence and monitoring checklist that a small developer team can run across dozens of locations

What the OWASP Top 10 Means for a Marketing Website

The Open Worldwide Application Security Project (OWASP) is a nonprofit that publishes free security guidance for web developers. Its best-known document is the OWASP Top 10, a ranked list of the most critical web application risks. The current edition is the OWASP Top 10:2025, which groups risks into ten categories such as broken access control and injection.

The list draws on data from security firms and community contributors. It describes risk types, not products. A marketing team should care because the list does not ask whether a site sells software or dental cleanings. Any site that accepts input, stores data, or runs code is in scope.

Why Marketing Sites Get Overlooked

Most teams treat a brochure site as low risk. It has no checkout, no customer accounts, and no payroll data. So it gets far less security review than the core product.

Attackers know this. A typical marketing site often has:

• A content management plugin that nobody has updated in months
• Third-party scripts for ads, chat widgets, and analytics
• A shared vendor login used by several agencies
• A lead form that writes directly into a CRM with broad access

Each item is a weak point. Together they give an attacker an easy way in, often easier than reaching the main product.

What a Compromised Brochure Site Costs

A hacked marketing site damages three things at once.

1. Search rankings. Google's guidance on hacked websites explains that hacked pages can be flagged, shown with warnings, or removed from results. A flagged site loses clicks it already earned.
2. Lead data. Form submissions carry names, phone numbers, and project details. A script injected into a form can copy every entry before your team sees it.
3. Brand trust. A visitor who sees a browser warning or an odd pop-up does not come back. That visitor may also warn a colleague.

Multi-location businesses feel this more sharply. A single template often feeds dozens of location pages and one shared form. One weakness can expose every branch at the same time.

Treat the Site as Production Software

The fix is not exotic. Patch the content management system on a schedule. Audit every third-party script. Limit who can log in, and remove access when agencies change. Our website team applies the same review to marketing sites that it applies to the product itself, because the risks are the same.

Key Insight: The OWASP Top 10 applies to a brochure site exactly as it applies to a banking app. A marketing site that collects leads is production software and deserves the same security review.

Broken Access Control in CMS Admin Panels and Staging Environments

Broken access control ranks first on the OWASP Top 10:2025 list, ahead of injection and security misconfiguration. For marketing sites, the risk often sits in the CMS admin panel rather than the front-end code. Three patterns cause most of the damage.

Overly broad editor roles

Most CMS platforms ship with default roles that are too powerful. The standard "Editor" role often can publish, delete pages, install plugins, and change site settings. A location manager who only updates hours and photos does not need any of that.

Common failures include:

• Regional staff set to Administrator so they never file a support ticket
• Freelancers who keep admin access months after a project ends
• Content staff who can install plugins or edit templates used by every location
• Users who can change the domain, billing contact, or analytics tags

Shared admin logins across locations

A single shared login for every location is common in small teams and breaks at scale. Nobody can tell who changed a page, and one departed employee keeps access to every site.

Rotating a shared password is also expensive. Suppose rotation takes 20 minutes per location. Across 60 locations, that is 20 hours of staff time before anyone touches content.

Publicly indexed staging URLs

Staging sites often sit on predictable subdomains with no login wall. Search engines find them through links, sitemaps, and certificate logs. Duplicate copies compete with the live site, and unpublished offers can leak before launch.

Robots.txt does not solve this. Google states that robots.txt is not a mechanism for keeping a web page out of Google. Staging needs real access control, such as HTTP authentication or an IP allowlist, with a noindex tag as a second layer.

A permissions model for multi-location teams

Use three tiers. Each tier maps to a clear scope.

1. Platform owner: One or two people at headquarters. They control plugins, templates, domains, and billing.
2. Brand editor: The central marketing team. They edit shared templates and global content but cannot change domains.
3. Location editor: Local staff. They update their own location's pages, hours, staff bios, and offers. They cannot publish global changes.

Limit each location editor to their own location's content. Review the role list every quarter, and remove anyone who no longer needs access.

Steps to enforce least privilege in the CMS

1. Export every user and role from the CMS.
2. Delete accounts tied to people who left or to finished projects.
3. Replace shared logins with one named account per person.
4. Build the three roles above and assign each user the lowest tier that covers their work.
5. Require multi-factor authentication for every admin and editor account.
6. Put staging behind authentication and an IP allowlist, then confirm it is absent from search results.
7. Log every role change and review the log monthly.

If your current CMS cannot scope roles by location, a website build designed for multi-location control avoids the problem at the architecture level.

Key Insight: Least privilege is a per-location cost decision, not only a security one. Every shared login and open staging URL adds hours of cleanup and a path for a leak across all of your locations.

Injection and Cross-Site Scripting Through Forms, Widgets, and Templates

Marketing sites look static, but they accept untrusted input in three common places:

• Contact and quote forms that store names, phone numbers, and messages.
• Location finders that take a ZIP code or city and echo it back on the page.
• Review widgets that render text written by customers and third parties.

Every field is untrusted. Treat it that way from the first byte.

For a hypothetical 40-location HVAC group, one contact form might feed a CRM, a location router, and an email template. Each hop is a place where a malicious string can change meaning.

Injection: Validate on the Server and Parameterize Queries

SQL injection happens when user text becomes part of a database command. Use parameterized queries or an ORM every time. Never join form values into SQL strings.

Validation rules that hold up in production:

1. Check type and length on the server, not only in browser JavaScript.
2. Allow-list expected characters for ZIP codes, phone numbers, and dates.
3. Reject or normalize anything outside the list before it reaches storage.
4. Cap free-text fields, such as messages at 2,000 characters.

Browser checks improve the user experience. They do nothing for security, because anyone can send a request that skips the form.

Cross-Site Scripting: Encode Output for the Context

Cross-site scripting (XSS) happens when the browser runs attacker text as code. Stored XSS is the worst case. A review saved with a script tag runs for every visitor who loads that page.

Encode output for where it lands. HTML body text, HTML attributes, JavaScript strings, and URLs each need different handling. Most modern template engines escape HTML by default. Developers break that default when they mark a value as safe or insert raw HTML.

<p>{{ review.body }}</p>


<p>{{{ review.body }}}</p>

In client scripts, write user text with textContent, not innerHTML. The same rule applies to map labels and widget titles.

Content Security Policy as the Backstop

A Content Security Policy (CSP) tells the browser which scripts it may run. Even if an injection slips past validation, the browser blocks unauthorized code. Start strict and add sources only when a feature needs them.

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-RANDOM'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'

• Generate a new nonce for each response and attach it only to approved inline scripts.
• Avoid unsafe-inline. It removes most of the protection CSP provides.
• Run Content-Security-Policy-Report-Only for two weeks, review violations, then enforce.

Third-party widgets are the usual reason a policy gets loosened. A hypothetical 40-location group with five review and map widgets could find a dozen script origins on its first report-only pass. Each one needs an owner and a reason to stay.

Teams that lack time to test these patterns can get them built into the launch. Our website development for multi-location brands includes template hardening and CSP rollout as standard work.

Key Insight: Validation stops bad input at the door, output encoding stops it from running in the page, and CSP stops it from running even if the first two fail. Build all three into the template layer before the first location goes live.

Need help applying this to your business? Tell us about your project and we will scope it with you.

Security Misconfiguration: Headers, Default Plugins, and Exposed Debug Output

Security misconfiguration is a setup problem, not a coding problem. The site works, but the server, content management system, or plugins run with settings that help attackers. Marketing sites get hit hard because they are built from templates and copied across locations. One weak default then repeats on every page of every site.

Missing Security Headers

Security headers tell the browser how to handle your pages. Most marketing sites send none of them. Add these five to every location's site:

1. Strict-Transport-Security: forces visitors onto HTTPS. Set max-age to 31536000 (one year).
2. Content-Security-Policy: lists the only sources allowed to run scripts. Start in report-only mode, because tag managers and chat widgets break easily.
3. X-Content-Type-Options: set to nosniff, so browsers do not guess file types.
4. X-Frame-Options: set to SAMEORIGIN, which stops other sites from framing your pages.
5. Referrer-Policy: set to strict-origin-when-cross-origin, which limits how much URL data leaves your domain.

Scan each site with a header checker after every deploy. A header dropped during a redesign is easy to miss.

Default Plugin Settings

Default plugin settings create some of the easiest openings. Installed tools often reveal version numbers, author pages, and readme files. They also leave login endpoints open under default usernames. Work through each plugin:

• Delete any plugin the site does not use.
• Hide version strings in page source and feeds.
• Rename the default admin account and require strong passwords with two-factor sign-in.
• Disable XML-RPC if no remote publishing tool needs it.
• Update plugins on a fixed schedule, not when someone remembers.

Verbose Error Pages and Debug Output

Debug mode exposes internals to anyone who triggers an error. Stack traces show file paths, framework versions, and sometimes database names. Turn debug mode off in production. Serve a plain 404 and 500 page with no technical detail, and send full error logs to a private server log.

Test it yourself. Request a URL that does not exist and read the response. If you see a file path, the site leaks information.

Directory Listings

A directory listing lets anyone browse folders such as /uploads/ or /backup/. Some servers enable this by default. Turn it off at the server level, then confirm by requesting a folder that has no index file. The correct response is a 403 error or a redirect, never a file list.

One Configuration Baseline for Every Location

Multi-location brands need one template, not dozens of hand-tuned sites. Apply this baseline to every location and audit it on a set schedule:

Store the baseline in one repository. When a location launches, it inherits these settings. When a setting changes, every site updates in one release. Teams that want this handled can start with the right service for websites or run a site audit to find gaps across locations first.

Key Insight: One header template and one debug-mode setting fix most marketing-site misconfigurations. The real cost is a single configuration pass per location, not a rebuild.

Headless CMS vs Traditional CMS: Security Surface Compared

Marketing sites usually run on one of two content models. A traditional CMS renders each page on the server when a visitor asks for it. A headless CMS stores content and serves it through an API, while a static build turns that content into finished HTML files ahead of time. The security profile of each model is different, and the gap grows with location count.

Attack surface

A traditional CMS exposes more of its stack to the public internet. The admin login, the database, the server runtime, and the public pages all sit on one system. Each layer needs patching, monitoring, and access control.

A headless setup separates those jobs. Editors log in to a private content tool. The public site serves prebuilt files from a content delivery network, so no live database query runs on each page view.

Patch burden

Traditional installs need regular updates to the core platform, the theme, and every plugin. A 40-location group running separate microsites may manage dozens of update paths. Each one can break a page or open a hole if it lapses.

Headless front ends still need dependency updates. The public runtime is smaller, though, and the hosted CMS vendor typically patches its own service. Your team owns fewer moving parts.

Plugin exposure

Plugins are a common entry point for traditional CMS breaches. Each one adds third-party code that runs on your server, often with uneven security review. Headless builds avoid most server-side plugins. Features arrive as components you control or as vetted third-party services.

API key handling

Headless sites depend on API keys. A typical build uses a read key for content, a preview key for drafts, and a key for forms or search. The most common mistake is placing a write-capable key in browser code. Follow these rules:

1. Use read-only tokens for public builds.
2. Keep publish and write keys in server-side environment variables.
3. Scope each key to one site or one location group.
4. Rotate keys whenever a staff member with access leaves.
5. Log key use and alert on unusual request volume.

Which architecture fits a 10 to 150 location brand

For most multi-location brands, headless or static wins. Pages load fast because they are prebuilt. Location pages can draw from one data source, which keeps hours, phone numbers, and offers consistent across every location. Maintenance drops because the public site has fewer parts that can fail.

A traditional CMS still fits when pages need live, complex personalization and you have in-house developers to patch it. Teams without that capacity should choose the lower-maintenance path. If you are weighing options, the right service covers how we build and host these sites.

Key Insight: For a 10 to 150 location brand without a large in-house engineering team, a headless or static site cuts both attack surface and patch work. Put the risk into key handling and build discipline instead.

Third-Party Scripts and Vulnerable Dependencies: Auditing the Tag Stack

Every analytics tag, chat widget, and ad pixel runs inside the same browser page as your own code. Once loaded, a script can read form fields, rewrite page content, and send data to any server it chooses. Your visitors cannot tell the difference.

That makes each vendor script a supply chain risk. You trust the vendor, but you also trust the vendor's own systems and every third party it loads. If one link breaks, your site becomes the delivery route.

The Polyfill.io incident showed how this plays out. A widely embedded JavaScript library changed hands, and the new owner began serving malicious code through it. Sites that never edited their own code were still affected.

Build a Script Inventory First

You cannot protect scripts you have not listed. Most marketing teams cannot name every script on their site.

1. Open each page template and list every script tag.
2. Check your tag manager for scripts added outside the codebase.
3. Record the owner, purpose, and approver for each script.
4. Remove anything no one uses. Unused tags add risk and no value.

Pin Versions and Apply Subresource Integrity

Load vendor files from a fixed version, not a floating "latest" path. A floating path lets a vendor change the code your visitors run without notice.

Subresource Integrity (SRI) adds a hash to a script tag. The browser refuses to run the file if the hash does not match. The MDN guide to Subresource Integrity explains the attribute and its limits. SRI works only on files with fixed content, so dynamic tag manager payloads need other controls, such as strict review of what the manager can load.

Review Advisories on a Fixed Schedule

Set a calendar cycle and keep it. Review direct dependencies monthly and the full tag stack quarterly.

• Run your package manager's audit command on every build.
• Check each vendor's security or status page.
• Log every change and who approved it.

The OWASP entry on vulnerable and outdated components covers the same risk category in more depth. Teams without the staff to run this cycle can get help from the right service for front-end build and maintenance, or request a site review to find unmanaged scripts first.

Key Insight: A script you never inventoried is a script you never reviewed. Build the list, pin the versions, and put advisory checks on a calendar before adding another tag.

Protecting Lead Forms From Bot Abuse Without Hurting Conversion

Lead forms are the most exposed part of a marketing site. They accept input from anyone, they write directly to your CRM, and many sit behind no login at all. Bots know this. The goal is to stop automated abuse without making real buyers work harder to contact you.

Why bots target lead forms and portals

Bots usually come for one of three reasons:

1. Spam submissions fill your CRM with fake contacts and links.
2. Credential stuffing tests stolen username and password pairs against customer portals.
3. Enumeration probes forms to learn which email addresses already belong to customers.

Each one costs you money. Sales reps chase fake leads. Compromised portal accounts create support tickets and trust problems. Junk records also distort reporting, so your cost per lead looks better or worse than it really is.

Layer 1: Honeypot fields

A honeypot is a form field that real visitors never see. You hide it with CSS, then label it with a name bots like, such as "website" or "company_url." Automated scripts fill every field they find. Any submission with a value in the honeypot gets rejected.

• Hide the field with CSS, not with the hidden input type, because many bots skip hidden inputs.
• Keep the field out of tab order so keyboard users never reach it.
• Reject silently, or show the normal thank-you page so bots get no signal.

Layer 2: Timing and server-side validation

Bots submit forms in well under a second. People take longer. Record the time the form loaded, then flag submissions that arrive in a few seconds or less.

Server-side validation matters more than browser checks. Anyone can disable JavaScript or replay a request. Check email format, field length, and allowed characters on the server, and never trust the browser to do it for you.

Layer 3: Rate limits and login protection

Rate limits cap how often one source can act. Apply them at three points:

• Form submissions per IP address, such as five per ten minutes.
• Login attempts per account, with a short lockout or a step-up challenge after repeated failures.
• Login attempts per IP address across many accounts, which catches credential stuffing.

Return the same message whether or not an account exists. Otherwise attackers learn which emails are customers. Add multi-factor authentication to customer portals, since reused passwords are what make stuffing work.

Where CAPTCHA fits

Use CAPTCHA last. It adds friction for every visitor, including the ones you want. Trigger it only when earlier layers flag a submission or an IP shows a pattern.

Imagine a 40-location HVAC group that puts a visible CAPTCHA on every form. Spam drops, but so does completion for customers trying to book service. Test before you roll out any challenge sitewide.

Measure lead quality and conversion together

Track completion rate and spam rate for each location's form. A well-layered setup should cut junk without moving completion. If completion falls, a control is too strict, so loosen it and retest.

If you want an outside review of your forms and portal logins, start with an audit of your current setup. If the forms need rebuilding, our website team can add these layers to a conversion-focused build.

Key Insight: Honeypots, server-side checks, and rate limits stop most bot abuse without a visible challenge. Save CAPTCHA for the traffic those layers flag, and measure completion rate alongside spam volume.

Monitoring, Patch Cadence, and a Developer Checklist for Multi-Location Sites

Location pages share templates, so one unpatched component can expose every location at once. A fixed patch cadence keeps that risk contained.

Patch cadence for location pages

Set a patch cadence that the whole team follows without debate:

1. Apply critical framework and dependency patches within 72 hours.
2. Apply high-severity patches within 14 days.
3. Review all other updates in a monthly maintenance window.
4. Ship every location page from one template, so one fix reaches all locations in a single release.

Developer security checklist

Use this checklist on every release:

1. Keep Next.js, Node.js, and all npm packages on supported versions.
2. Run a dependency scan on every pull request.
3. Store secrets in an environment manager, never in the repository or the client bundle.
4. Validate and escape all form input on the server, not only in the browser.
5. Require multi-factor authentication and role-based access for the CMS and admin routes.
6. Set a Content Security Policy and secure cookie flags.
7. Rate limit form and login endpoints.
8. Restrict each location editor to that location's pages.
9. Test backup restores on a set schedule.

Logging and alerting for form and admin events

Log every form submission, admin login, failed login, permission change, and page publish. Keep personal data out of the logs. Send them to one central store with retention set by your compliance team.

Alert on these patterns:

• Five failed admin logins within 10 minutes for the same account.
• A new admin user created outside a change ticket.
• Form submission volume that jumps well above its weekly baseline, which can signal spam or bot abuse.
• Any publish event on a location page outside business hours.

How this works in a real rebuild

DDES, an economic research and workforce development organization, received a performance-focused Next.js rebuild with full Search Console integration and AI and LLM search optimization. The organization went from effectively invisible on Google to indexed and ranking for high-intent research queries. That case study covers the build and search work, not a security audit, so it makes no security claims. Read the DDES rebuild details for the full scope.

A checklist like this one belongs in every rebuild from day one. Teams that want the build and the hardening handled together can start with our website build service.

Key Insight: Patch speed and alert coverage matter more for multi-location sites than any single tool. One template, one patch cycle, and one alert rule set protect every location at the same time.

Sources and References

Primary sources cited above:

• OWASP Top 10:2025
• OWASP Top 10:2025 list
• robots.txt is not a mechanism for keeping a web page out of Google
• MDN guide to Subresource Integrity
• OWASP entry on vulnerable and outdated components