Unsafe suggestions to refuse

Why would an AI assistant suggest unsafe code?

An AI assistant learned from a huge amount of public code, and a lot of public code is written to work quickly, with safety left for later. Short answers on forums, old tutorials and quick demos all reach for the shortest line that makes the page change. The assistant repeats those patterns because they are common, and it rarely knows which of them belong on a real site that strangers will use.

It also wants to please you. If you ask for something that works, it gives you something that works in the Preview. Safety problems almost never show up in the Preview, because you are the only person typing into your own page. They show up later, when somebody types something you did not expect.

None of this means AI help is dangerous by default. Most of what it writes for a small website is fine. It means you need a short list of patterns that make you stop and ask, and the habit of reading every line before it goes live.

What makes innerHTML risky with visitor input?

Setting innerHTML tells the browser: read this string as HTML and build whatever it describes. That is handy for text you wrote yourself. For text a visitor typed, it means the visitor decides what HTML goes into your page. A name typed as <b>Robin</b> turns bold. Something nastier can add an image that loads from another server, a fake login box, or code that runs in the page of every person who sees the note.

This kind of hole is called cross-site scripting. You do not need to know how attacks are built to avoid it. You only need to notice where untrusted text ends up and make sure it goes in as text.

The guestbook reply in the practice area looks harmless. Use its code, type a name with angle brackets in the Preview, and watch the tags turn into formatting. That small surprise is the whole problem in miniature.

li.innerHTML = '<strong>' + who + '</strong>: ' + seen;

What should you use instead?

Build the structure with your own code and put visitor text in with textContent. The browser then shows the exact characters the visitor typed, angle brackets and all, and never treats them as tags. append with a string does the same thing, because a string passed to it becomes a text node.

You keep the bold name. You make the strong element yourself, fill it with textContent, and add it to the list item. It is four lines instead of one, and each line is easy to read. If you ever see an AI answer that builds HTML by gluing strings together with a visitor's words in the middle, this is the fix to reach for.

const strong = document.createElement('strong');
strong.textContent = who;
li.appendChild(strong);
li.append(': ' + seen);

Which other suggestions should make you stop?

The same idea, text from outside being treated as instructions, shows up in other places. Learn to recognise the shape and you will spot it in code you have never seen before.

When you are unsure, ask the assistant directly: "Is any of this unsafe if a visitor types something unexpected?" A real AI tool often catches its own mistake when asked that way. Treat its answer as a second opinion, and still read the code yourself.

• eval on anything a visitor typed. It runs text as JavaScript. Use Number() for numbers and plain comparisons for everything else.
• A script tag pointing at an address you do not recognise. That script can read and change your whole page, and its owner can change it tomorrow.
• Database queries built by gluing a visitor's words into the query text. The SQL course shows the safe way, called parameters, where the database keeps the query and the values apart.
• Commands that throw work away, such as git reset --hard or forced pushes, suggested as a quick way to fix a messy repository. The Git course covers what they delete and the gentler commands to try first.
• Any advice to turn off a security feature to make an error go away: disabling the browser's warnings, opening a server to every address, or switching off checks "for now".

Why is "just turn off security" such a common answer?

Many errors exist because a protection did its job. A browser blocks a request to another site, a server refuses an unknown visitor, a tool warns that a file is unsafe. When you paste that error into a chat, the quickest way to make it disappear is to remove the protection, and the assistant has seen that answer many times in old forum threads.

The error goes away and the hole stays. A better request asks for the reason first: "Explain why the browser blocks this, and show me the safe way to allow only what I need." The answer is usually a small, specific change, such as allowing one address or fixing a setting for one folder, instead of switching everything off.

How do you check AI code for these patterns?

You do not need a security tool for a small site. Use the browser's find box on the code, or the Code tab here, and search for a few words: innerHTML, eval, document.write, http://, and any <script src= you did not add. Each match is a place to slow down and ask where the data comes from.

Then test with odd input. Type a name with angle brackets, a very long sentence, an empty box, a number with letters in it. A safe page shows strange input as plain text and carries on. An unsafe one changes its own layout or breaks. The **Review** view helps afterwards: it highlights every line you changed, so you can confirm each fix is really there.

How do you ask for safe code from the start?

Add a safety limit to your request, in the same spot where you would say plain HTML and CSS only. Name the risk in everyday words: "visitors will type into this, so treat their text as plain text" or "do not use eval or innerHTML with user input". The assistant follows limits well when you state them.

That limit lowers the risk and never removes your job of checking. Real AI tools sometimes agree with a limit in their explanation and then break it in the code. Read the code for the patterns above even when the reply says it is safe.

Please add a script that shows each guestbook note in the #comments list. Visitors type these notes, so treat their text as plain text. Use plain JavaScript only, and do not use innerHTML or eval.

What does the pretend assistant leave out?

The assistant on this page is pretend. It runs in your browser, never goes online, and picks from replies written for this exercise, so the same kind of request always gets the same answer. Real AI tools vary their answers, and some will add safety checks unasked while others will not, even for the same request on the same day.

Real sites also need more than the browser side. If guestbook notes were saved on a server and shown to everyone, the server would need to treat them as untrusted too. The habit you practise here, follow the visitor's text and keep it as text, carries straight over to that work.

Field notes

• Assistants repeat quick public code patterns, and many skip safety.
• innerHTML reads a string as HTML, so a visitor could decide what goes into your page.
• textContent shows exactly what the visitor typed and never treats it as tags.
• Search AI code for innerHTML, eval and document.write before you keep it.

Easy to get wrong

You are the only person typing in your own Preview, so nothing odd happens. The risk appears when a stranger types something you did not plan for, and by then the page is live.

Protections exist to stop real problems. Switching one off hides the error and leaves the problem for your visitors to find.

Commands like git reset --hard throw away uncommitted work with no undo. A minute of checking costs less than an afternoon of lost changes.

Questions people ask

Is innerHTML ever fine to use?

Yes, for HTML you wrote yourself, such as a fixed message or a template with no outside text in it. The problem is mixing in text from visitors, from a URL, or from another service.

Does a small club site really need to worry about this?

Small sites get hit by automated scripts that try the same tricks on thousands of pages. Fixing the pattern costs a few lines, and those few lines also make the page behave better when someone types odd characters by accident.

Can I ask the AI assistant to check its own code for safety?

Yes, and it often helps. Ask it to list where visitor input goes and whether any of it is treated as HTML or code. Read its answer as one opinion and still check the code yourself.

What if I already put unsafe code on my site?

Fix the code, then look at any stored notes or comments for odd tags or scripts and remove them. If the page handled logins or private data, ask someone experienced to look it over.