How to build safe commands, safe add-ons, and secure backend integrations

The Cointacted Social Terminal is extremely safe by design.
But add-ons, custom commands, and REST logic can introduce vulnerabilities if developers are not careful.

This guide teaches:

• what you MUST NOT do
• what you SHOULD do always
• how to sanitize input
• how to validate output
• how to protect REST routes
• how to check permissions
• how to avoid XSS
• how to avoid dangerous JS behaviors

These rules keep your ecosystem secure and ensure WordPress.org approval.

---

✅ 1. Never Trust User Input (Sanitize Everything) #

Every command receives:

input.raw   // full text
input.cmd   // command keyword
input.args  // array of arguments

These values are untrusted.

❌ Never do: #

eval(input.raw);
innerHTML = input.raw;

✔ Always sanitize: #

• in JS if needed
• in PHP with proper functions

Examples (PHP):

sanitize_text_field()
sanitize_user()
sanitize_email()
esc_url_raw()
absint()
floatval()

---

✅ 2. Output Escaping — HTML Is Escaped by Default #

The terminal intentionally escapes HTML to prevent XSS.

Example:

cointacted_social_terminal_append_line("<b>Hello</b>", "system");

Will output:

<b>Hello</b>

NOT bold text.

This prevents:

<script>alert("XSS")</script>

Developers must NOT bypass this unless:

• you fully trust the source
• you build a special output type with controlled HTML
• you sanitize and whitelist allowed tags

HTML output is strongly discouraged.

---

❌ 3. Do NOT use innerHTML directly #

Dangerous:

element.innerHTML = userInput;

This is how XSS happens.

DO NOT DO THIS in your add-ons.

---

⚠️ 4. Do NOT enable wallet actions in core commands #

Core terminal = read-only.
All wallet interactions must be inside add-ons.

A developer add-on must never:

• auto-request wallet connection on page load
• auto-sign messages
• auto-send transactions
• request wallet perms without user action

This violates:

• WordPress guidelines
• MetaMask guidelines
• browser security norms

---

⚠️ 5. Always Enforce Permissions in REST Routes #

Every secure endpoint must:

1. Check user is logged in #

2. Validate user role #

3. Sanitize inputs #

4. Return WP_Error on failure #

5. Never expose sensitive data #

Example (GOOD):

'permission_callback' => function() {
    return current_user_can('manage_options');
}

Example (BAD):

'permission_callback' => '__return_true';

when endpoint contains private data.

---

⚠️ 6. Never expose raw user data in commands #

Do NOT output:

• emails
• private user_meta
• tokens
• internal fields
• admin-only info to guests

Guest-safe commands are already enforced by the core.
Add-ons must respect this too.

---

⚠️ 7. Avoid Long-Running Loops or Blocking Code #

These can freeze the terminal:

while(true) {}

Or:

for (let i = 0; i < 1e12; i++) {}

Always use async or setTimeout for heavy tasks.

---

⚠️ 8. Don’t Block the UI with Alerts or Prompts #

Simple alerts are OK, but blocking loops of popups are dangerous:

alert("spam");
alert("spam");
alert("spam");

Avoid infinite alerts.

---

⚠️ 9. Do NOT Override Core Commands Sloppily #

Bad example:

CointactedSocialTerminalTerminal.registry.help = "haha hacked";

This breaks:

• help system
• search
• metadata
• alias linking

If you override, always override with a function.
Or wrap safely:

const old = registry.help;
registry.help = function(input) {
    // your logic
    old(input);
};

---

⚠️ 10. When Handling External APIs, Validate Everything #

Example (BAD):

const price = data.market.usd; // may not exist

GOOD:

if (!data || !data[coin] || !data[coin].usd) {
    append_line("Invalid API response.", "error");
    return;
}

Never assume API shape.

---

⚠️ 11. Avoid Leaking Technical Data to Guests #

Even harmless things may be misused:

• server IP
• site internal URLs
• debug traces
• user IDs
• capability lists

Always check:

if (!CointactedSocialTerminalTerminal.user?.is_logged_in) {
    return append_line("Login required.", "error");
}

---

⚠️ 12. Don’t Save Sensitive Data in LocalStorage #

LocalStorage = readable by any script on the page.
Do NOT store:

• wallet private data (never store keys anywhere!)
• tokens
• JWTs
• user personal data

Safe to store:

• harmless preferences
• text notes
• settings
• modes

---

🚫 13. Never Use eval() EVER #

Don’t do:

eval("alert('bad')");

Not even for testing.

---

⚠️ 14. Avoid Third-Party CDN Scripts in Add-Ons #

WP.org rules require:

• scripts must be in plugin folder
• OR loaded from WP core

Do not load JS from:

• CDN
• untrusted domains

Security risk + wp.org rejection.

---

⚠️ 15. Validate All Input Before Using It #

Example (sanitize number):

const n = parseInt(input.args[0]);
if (isNaN(n)) return append_line("Number required.", "error");

Example (sanitize string):

const text = input.args.join(" ").replace(/[^a-zA-Z0-9 .,!?_-]/g, "");

---

👍 Safe Patterns Summary #

✓ sanitize input #

✓ escape HTML #

✓ check permissions #

✓ validate REST parameters #

✓ whitelist roles #

✓ use REST instead of ajax whenever possible #

✓ return JSON objects only #

✓ handle all errors gracefully #

✓ wrap overridden commands #

✓ keep wallet logic in add-ons #

✓ use async to avoid blocking #

This keeps both developers and users safe.

---

🎯 Summary #

Security for developers means:

• never trusting input
• validating everything
• escaping output
• protecting backend routes
• respecting user permissions
• avoiding dangerous JS patterns
• keeping wallet logic safe
• following wp.org rules

By following these rules, add-ons built by your community will remain safe, stable, and WordPress-approved.