Every User Submissions & Moderation Audit check

Submitters who discover missing or invalid fields only after hitting submit waste a full network round-trip, lose their place in the form, and frequently abandon. Directories that rely on server-only validation bleed 20-40% of completion rate on multi-field listings and push that friction onto the moderation queue as half-filled drafts. Inline field-level errors on blur catch mistakes at the point of input, keep scroll position intact, and give assistive technologies an accessible hook to announce problems, which matters directly to WCAG 2.2 SC 3.3.1 (Error Identification) and SC 3.3.3 (Error Suggestion) conformance.

Why this severity: Critical because missing client validation directly tanks submission completion and violates WCAG 3.3.1/3.3.3 accessibility requirements.

Client-side validation is advisory — any attacker with curl can bypass it entirely. Without server-side enforcement on every field, a crafted POST with a missing title or malformed email doesn't get rejected at 400; it either crashes the handler with a 500 (leaking stack traces) or silently inserts garbage into your database. OWASP A03 (Injection) and CWE-20 (Improper Input Validation) both call this out as a critical failure mode: the server is the only trust boundary that matters.

Why this severity: Critical because client-side bypasses are trivial and unvalidated inputs can cause 500 errors, crash handlers, or corrupt the database directly.

A directory without a moderation queue is an open invitation for spam, defamatory content, and phishing links — all published the instant a form is submitted. Every public query that lacks a `WHERE status = 'approved'` filter exposes every pending, rejected, and spam entry to visitors. This violates OWASP A01 (Broken Access Control) and CWE-285 (Improper Authorization): your access control policy says only approved content is public, but the data layer does not enforce it.

Why this severity: Critical because auto-published submissions bypass all editorial control, exposing spam and harmful content to every visitor immediately.

An unprotected submission form is an automated spam target. Bots discover open endpoints within hours of launch and flood moderation queues with hundreds of fake listings per minute. Without CAPTCHA, a honeypot field, or server-side rate limiting, your moderators are overwhelmed, storage costs spike, and legitimate submissions get buried. CWE-799 (Improper Control of Interaction Frequency) and OWASP A07 (Identification & Authentication Failures) both apply — the server cannot distinguish human from bot because it never asks.

Why this severity: Critical because an unguarded form enables unlimited automated spam that overwhelms moderation queues and degrades directory quality for every real user.

Accepting unvalidated URLs in a directory creates two distinct attack surfaces: phishing (a listing points visitors to a credential-harvesting domain) and open redirect abuse (your platform lends credibility to malicious links). CWE-601 (Open Redirect) and CWE-20 (Improper Input Validation) under OWASP A03 both cover this. A blocklist is not optional — URL format validation alone accepts `https://known-phishing-domain.com` without complaint.

Why this severity: Critical because accepted phishing URLs appear on your platform under your domain's authority, directly exposing visitors to credential theft and malware.

Listing claim flows that verify only the claimant's own email let any account take over any business listing by clicking a link sent to themselves. The attack is trivial: submit a claim request for a competitor's listing, confirm the email that arrives in your own inbox, done. OWASP A01 (Broken Access Control), CWE-285 (Improper Authorization), and CWE-287 (Improper Authentication) all apply. The verification must reach the listing's on-file contact, not the claimant.

Why this severity: Critical because self-email verification allows any user to fraudulently take ownership of any listing, including competitors' businesses.

File uploads validated only by extension are trivially bypassed: rename `shell.php` to `shell.jpg` and upload. Without MIME type inspection via magic bytes and enforced server-side size limits, attackers can store and potentially execute malicious payloads on your server, or exhaust storage with multi-gigabyte uploads that bypass client-only size caps. CWE-434 (Unrestricted Upload of File with Dangerous Type) and OWASP A03 cover this directly.

Why this severity: High because successful malicious file upload can lead to remote code execution or storage exhaustion, though exploitation requires the server to execute the file or lack adequate sandboxing.

When a submitter clicks submit and gets no email back, they assume the form dropped the request and either re-submit (creating duplicate moderation work) or abandon the directory entirely. Confirmation emails with a tracked submission ID and status link reduce duplicate submissions, cut support volume on "did you get my listing?" tickets, and give the business a legitimate re-engagement channel when the listing is approved. Absent confirmation also breaks CAN-SPAM and GDPR Article 13 transparency expectations around acknowledging data collection at the point of intake.

Why this severity: High because missing confirmation drives duplicate submissions, support load, and transparency gaps without directly exposing data.

Without an audit log of moderation actions, you cannot answer basic questions: Who approved the listing that turned out to be a scam? Was a rejection justified? When did a moderator act? This absence blocks compliance with ISO 27001:2022 A.8.15 (Logging) and makes CWE-778 (Insufficient Logging) applicable. Beyond compliance, an unlogged moderation system offers zero accountability — moderators can approve or suppress listings without any record.

Why this severity: High because missing moderation logs eliminate accountability, prevent abuse investigations, and fail ISO 27001:2022 A.8.15 logging requirements.

A rejected submission that generates no notification leaves the submitter with no recourse: they do not know the listing was rejected, why it failed, or how to fix it. This silently degrades the directory's submission funnel — legitimate businesses give up and post elsewhere. It also creates GDPR Art. 17 exposure if a user later requests deletion of data that was never communicated to them as rejected. The submitter's time and data were consumed with zero return.

Why this severity: High because silent rejections destroy submitter trust, suppress resubmission of valid listings, and leave users unable to exercise data rights they don't know are triggered.

Treating anonymous and authenticated submissions identically removes a key signal the moderation queue needs to prioritize risk. Anonymous submissions cannot be traced, appealed, or associated with a reputation history — they are statistically higher-risk. OWASP A07 (Identification & Authentication Failures) applies when the system cannot distinguish the source of an action. Without auth differentiation, a bot network using throwaway emails receives the same moderation weight as a verified long-standing user.

Why this severity: High because anonymous submissions indistinguishable from authenticated ones give spam and abuse the same moderation path as legitimate submissions, increasing moderator burden and queue pollution.

Without batch rate limiting, a single IP can submit hundreds of listings per minute, flooding the moderation queue and making it impossible for human reviewers to process legitimate submissions. CWE-770 (Allocation of Resources Without Limits) and OWASP A05 (Security Misconfiguration) both apply. The cost is not just operational — spam that slips through moderation poisons the directory's data quality for every downstream user and search engine that indexes it.

Why this severity: High because uncapped submission rates enable queue flooding that incapacitates moderation, drives up infrastructure costs, and degrades directory data quality at scale.

A verified owner badge that is set client-side or derived from user-supplied input is cosmetic — any user can fake it by editing the DOM or intercepting the API response. Visitors rely on the badge to distinguish operator-managed listings from third-party submissions. When the badge is fabricated, trust signals collapse and the directory's credibility is undermined. CWE-285 and OWASP A01 (Broken Access Control) apply: authorization state must always originate from the server.

Why this severity: High because a client-side or user-controllable badge can be faked by any listing submitter, making the verified owner signal meaningless to visitors.

Allowing listing owners to directly overwrite approved content gives any compromised or malicious owner account the ability to replace a legitimate listing with spam, phishing links, or defamatory text that goes live instantly. CWE-285 (Improper Authorization) and OWASP A01 apply — ownership of a listing does not grant the right to bypass editorial review. This is especially acute because a single bad edit can damage the directory's SEO and brand before any moderator notices.

Why this severity: High because direct-overwrite edits allow a malicious or hijacked owner account to publish harmful content to a live, indexed listing with zero moderation delay.

Hard-deleting reported listings destroys the evidence needed to investigate abuse patterns, respond to legal holds, and meet GDPR Art. 17 obligations (which require a deliberate erasure decision, not automatic deletion on report). CWE-778 (Insufficient Logging) applies: if the record is gone, you cannot determine whether the report was legitimate, who submitted the listing, or whether the reporter is gaming the system to suppress competitors.

Why this severity: Medium because hard deletion on report removes audit trails and creates GDPR Art. 17 compliance gaps, but the primary impact is operational rather than an immediate security breach.

A sitemap that leaks pending, rejected, or suspended listings feeds search engines URLs that return 404, soft-404, or thin-content pages, which tanks crawl budget and suppresses ranking for the listings that are actually approved. Worse, indexed-then-removed URLs can surface moderator-rejected content (spam, fraud, or policy violations) in Google results for days before re-crawl, exposing the directory to reputational risk and potential liability under platform-intermediary rules like DSA Article 16 on notice-and-action transparency.

Why this severity: Medium because the leak is public-facing and wastes crawl budget but does not directly expose user data or credentials.

Keyword stuffing, excessive link insertion, and spam phrases in listing descriptions are direct attacks on your directory's search ranking and user trust. If they reach the public index, search engines penalize your domain; if they reach users, they damage the directory's reputation as a quality resource. CWE-79 (XSS) applies when unscanned descriptions contain injected script tags. OWASP A03 covers the broader input trust failure. Automated detection gates the moderation queue so human reviewers see pre-filtered content.

Why this severity: Medium because spam descriptions degrade directory SEO and user trust, but the direct security impact depends on whether XSS payloads are also filtered downstream.

When listing owners cannot close their own listings without contacting support, closed or defunct businesses remain in the directory indefinitely — polluting search results, misleading visitors, and generating dead-end clicks. GDPR Art. 17 (right to erasure) creates an obligation to honor removal requests promptly; routing that through a support ticket introduces unnecessary delay. CWE-285 applies when the authorization model lacks a scope the owner clearly should have: control over their own content.

Why this severity: Low because the failure is primarily a UX and data-quality gap — stale listings mislead users — rather than a direct security vulnerability.