The news.arc code writes to files. It doesn't use an SQL database.
Even without SQL, code injection is something to worry about. The Arc codebase is a breeding ground for exactly this kind of issue, since it rarely does string escaping. Let's see...
HTML injection (XSS attacks): This is the kind of injection news.arc primarily needs to worry about. Almost every string it passes around is used directly as an HTML code snippet. Fortunately, every user input is sanitized thanks to the form-generating utilities in app.arc.
Shell injection: Make sure that any directory paths passed to (ensure-dir ...) are already shell-escaped. (Arc also invokes the shell in a few other places, but those don't need any extra escaping.)
Arc injection: The prompt.arc webapp is explicitly designed to let admin users evaluate their own Arc code on the server. If an attacker gained access to this page, it would be worse than any other kind of code injection. Because of this, I don't recommend running prompt.arc on a production site. (If it can't be helped, I recommend at least using HTTPS so admin login credentials and commands can't be intercepted by a man-in-the-middle attack.)
Yeah, that's something I'm trying to think about with the current project that I'm working on. Part of why I brought up mongodb support. Maybe something like datomic would be better.
Starting with simple files is actually really convenient and takes very little effort. Only fixing things that need fixing is a good way to make progress quickly, but it is a little disconcerting not to have many options to switch to.
Maybe building a simple arc-based database would be a good idea, but that also distracts from solving the actual problems I'm working on. Which did not initially include making a new database, as much fun as that would be.
I was working on a simple git-based data storage system for arc as part of my 'metagame' project. Not exactly designed for multi-server use though.