Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
How do websites built by website builders defend security threats or follow secure coding?
There are SaaS providers for building and hosting websites made with WYSIWYG and LLM-prompt website builders, such as WordPress.com, Webflow, etc. I guess these services should be secure-by-default and secure-by-design, e.g. the builders should be guided to generate code to follow secure coding in JavaScript, and the hosting providers should provide automated vulnerability detection. However, I'm not sure if the generated code can effectively defend against security threats or likely attackers.
In my understanding, most components are merely HTML snippets, so they are bullet-proof. Dynamic components like routing, login, payment or APIs to third-party services can be made secure-by-default and secure-by-design. So a toy made from secured lego bricks should be secured as well? I wonder if the security decreases when LLMs are involved, because at the end of the day they can introduce new code that is not provided by the builders?
And what certifications would be relevant on this? For example, the security page of Webflow has information about the product security (Webflow itself), with various certifications. There are also places where they say the websites built by their builder are secured, but I'm unable to see how they defend security threats (broken access control, injection, etc.) or follow secure coding (cross-site scripting, inline script, etc.).
1 answer
My understanding (from sometimes working on the older form) is that your instinct hits pretty close to the mark. It often depends on what you need and (increasingly importantly) how rigid a system you have.
For a "what you need" example, consider Stripe. You have an account with them, and you can either send your traffic to their site, or they'll provide a blob of JavaScript that will insert their widgets into the page. You can't build a full store and shopping cart that way, because that requires communicating back and forth, but most people can accept that gap. They handle the security, in other words. Most providers work that way.
On the rigidity side, as you suggest, as long as you drop in fixed components, flaws might creep in, but Stripe-or-whoever has a strong motivation to not let fraud bounce around their system. But as the system becomes more flexible, letting developers (and these people do develop software, even if not for a living) do whatever they want will inevitably open security hole.
Sometimes, you don't even need the developer to do anything, such as with WordPress's long reputation as a primary target for hackers pushing spam and malware to readers. Because WordPress became so popular, you had many more people interested in attacking it than Automattic had cleaning up security holes. But LLM-based systems almost certainly have security problems, because LLMs introduce security vulnerabilities in almost half of all changes, turns out...
None of the site-builders has some secret tool that carefully validates the security, though. If they did, then we'd hear about it, because selling that tool would net them orders of magnitude more money than helping college kids sell bracelets and the like.
1 comment thread