addslashes() in data-confirm attributes shows a literal backslash in BBS confirm dialogs

Area: mobieusMarket / BBS (audit p3) · Surface: /bbs (Featured + Community BBS listings) · Dimension: native-dialogs · Severity: minor

Every BBS row builds its data-confirm message with `$e(addslashes($name))`. `$e()` (htmlspecialchars, ENT_QUOTES) already makes the value safe inside the HTML attribute, so the extra addslashes is both unnecessary and harmful: a BBS named "Joe's BBS" produces the attribute `Report 'Joe\'s BBS' as down?`. The confirm modal renders the message with textContent, so the user sees a stray backslash: "Report 'Joe\'s BBS' as down?". Affects 6 confirm dialogs (report-down, demote, remove, promote on both Featured and Community listings).

Evidence

platform/templates/bbs/index.php:82 `data-confirm="Report '<?= $e(addslashes($bbs['name'])) ?>' as down?">` (also lines 97, 107, 268, 283, 293). The data-confirm handler in platform/public/js/app.js:1369-1382 reads `btn.getAttribute('data-confirm')` and passes it to App.modal.confirm, which renders via `p.textContent = message` (platform/public/js/app.js:486). getAttribute returns the un-HTML-decoded but addslashes-mangled value, so textContent prints the literal backslash.

Suggested fix. Drop addslashes everywhere in bbs/index.php; use just `$e($bbs['name'])` / `$e($entry['name'])`. htmlspecialchars with ENT_QUOTES already encodes both ' and " safely for the attribute, and the modal reads the decoded value cleanly.

Filed by the automated tenant-app audit and adversarially evidence-verified. Status: verified. Open — not yet actioned.