This module, as currently implemented, is not strictly a parser, it's a Turing Machine. The nice thing about JSON is that it requires, at most, a context-free grammar (CFG) in order to parse it. CoffeeScript requires a context-sensitive grammar, meaning that you need more computational power -- not quite a Turing machine, but more powerful than a CFG, thus making parsers for it harder to secure.
So I was a little concerned about the security of this module, and I checked out the code. I spotted the section that boils down to:
result = JSON.parse(src)
result = coffee.eval(src, opts)
result = err
So, it's worse than a context-sensitive grammar, you're basically evaluating arbitrary CoffeeScript, which is a Turing machine. This means I can lock up the process by doing something like:
cson.parseSync('while true\n "hi"')
Since this module will run arbitrary code, either stop calling it a parser, or turn it into one that is provably not Turing-complete. You should probably also warn your users, insofar as you are able, about this in case they are using CSON to parse untrusted data.
Added note for #32
Thanks for raising this. With the increased popularity of CSON due to atom.io (they don't actually use this parser, but they do the same thing is as this parser, source), a lot of people may be thinking of using CSON for something else than what it's actually intended for.
For us personally (which appears to be the same case for atom.io), it's the ideal use case as CSON is being used for developers writing their own configuration to be executed on their own machines on their own systems, in a completely trusted environment. For others using CSON, this certainly may not be the case (although I can hardly come up with another use case where CSON makes sense to honest... hence why this has never been considered to be an issue until now, because for our use cases of CSON, it truly hasn't been).
Due to the concern though, I've added a warning and explanation about this to the README as per your suggestion with: https://github.com/bevry/cson#use-case
If on the other hand, someone is happy to make this a parser that doesn't execute code, that would be great! I'd happily merge their pull request, as it certainly would be cool to open up CSON to more use cases than just our own. I've created issue #33 to facilitate this.
CSON, unsafe but secure: bevry/cson#32