Is Node.js mature for enterprise security?

Although I can't point to any specific reported defects, I'd be nervous about the node.js architecture - where your code runs as part of the webserver code. While with something like mod_php, there is still only a single process handling both the HTTP and logic tiers, there is a clear functional separation between the 2, and the interface between the webserver and the logic tier has been expressly designed and tested to accomodate failures - particulary in the logic tier.

Also, there are a lot of tools available for webservers (Apache in particular) which facilitate management and (used properly) enhance security.

Another major consideration is availability of skills/support/training - regardless of its quality / utility, node.js has a lot of catching up to do compared with other web development platforms.

Our development team has been considering using Node.js

That you are specifically trying to deliver what should be a very secure application on a platform which (judging from your statement above) you are not thoroughly familiar with seems to be very reckless. Most security vulnerabilities in web applications arise not because of faults in the development environment but in faults in the bespoke code added on top.

Certainly using a reverse proxy would facilitate getting standard HTTP logging, anomoly detection and reduce impact of protocol level attacks.

One of the best tools for building secure web applications is mod_security - AFAIK, this is only available to run within Apache - but it would offer the possibility (along with mod_proxy) of deploying a front-end system providing the usual webserver functionality (logging, static content) along with, say, authentication services, and using node.js as a backend.

It mostly helps with concurrency if that concurrency is IO bound as you probably know.

An option that is a lot faster than NodeJS is to use mono + F# and its async support. Then you can use a HttpListener to get as close to the socket as with NodeJS.

Oblivious to the choices above; SELinux and chroot are probably good tools for the rest.

Most security vulns in code in my experience, that result in executing arbitrary code are from either bad write permissions to database/disk allowing you to request files that you've uploaded, or from unmanaged code that does bad memory management/bounds checking.

A reverse proxy is also a good option, because they are battle hardened. HAProxy e.g. - it can handle both WebSockets and normal HTTP in its latest versions.

Then you can use some tooling to actually test the implementation. Google uses a tool call skipfish: https://code.google.com/p/skipfish/

You can use a fuzzer on the protocol level as well as app level, but that's of less and less importance the more your compiler proves for you, like with JS where you can't change the type of an object instance or F# where you have more static checking with e.g. discriminated unions and units of measure.

Finally, if you are after really high code security, I would recommend Stact Framework with Haskell which you can make very security using the compiler. With Haskell you can even write small proofs with Coq, a proof assistant, or Agda (see Haskell Theorem Provers)

In order to communicate with your servers, you're probably going to have a DNS. You'll need to secure that as well, with DNSSec, or you can get DNS Poisoning.

If they gain access to the LAN, you can get ARP Poisioned, meaning someone can steal your IPs; but you can make the DNS server to static maintenance of whoever is on the network in an IP-to-MAC lookup table that all hosts also check.

Finally, you can add an IDS like Snort to your network and record a "normal" execution of your program, so that you can also be reactive to anomalies.

Ideally, the entire application should be restricted either by an intranet or a VPN, or at the very least IP address of the client, especially if it is going to be used by any sort of Federal officer. If the attacker can't even hit the web server, then they certainly won't be able to exploit Node.js, right?