_spartan
node application to package & configure common security middleware into your application
AUDIENCE
_spartan was created for developers of node.js applications, not security people. I am 100% convinced that no developer wants to be the one to write the line(s) of code that leads to innocent people having their credit ruined (amongst other things). I'm also 100% convinced that developers don't always know what they need to add/change/remove in their applications to make it "secure". And, selfishly, I made _spartan for me, because I'm tired of "whack-a-mole" security, "hope-and-pray" security and playing the "is it a risk really?" game with developers.
THIS. IS._SPARTAN!
- You define and configure your application's security policy by answering a series of questions about the app
- _spartan generates a
security.json
file which essentially serves as the technical specification of your application's security policy. This file ultimately serves three purposes:- It is the basis upon which the
security.js
file is created. More on that below. - It is your application's security policy. This is a really quick, easy thing you can show to auditors or push into your org's downstream auditing engines.
- It is the entry-level requirement to use with
_phlanax
. I won't belabor the point here, but if your app is a microservice operating as part of a larger web application platform, _phlanax ensures that all of the other apps in the platform are operating at a common security level.
- It is the basis upon which the
- We parse the policy file and generate
security.js
which contains the boilerplate code that you will actually wire up in your app. - We update the
package.json
file with any/all modules required to make this whole thing work. All you have to do is:require($PATH/security.js)
THIS. IS. NOT._SPARTAN!
- _spartan is not intended to make your app completely 'breach proof'. After all, if your app's business logic is such that it creates or introduces a vulnerability, _spartan will not be able to influence that. _spartan will allow your app to be built from a 'secure by default' baseline so that developers, architects and product owners can make deliberate, measurable security risk decisions.
- While the security.json file serves as a great way to describe and attest to your application's security policies, it is not the only thing you need to have or present in order to pass an audit. Stay tuned for a PR that includes an audit-only role which will not only produce the security.json policy, but also the
.snyk
vulnerability report and a basic code review.
USAGE!
-
_installation
Installing _spartan is straightforward:
- First install the utility:
$ npm install -g spartan-shield
- Note : this assumes you have already built your app (and package.json) with
npm init
- Note : this assumes you have already built your app (and package.json) with
- Next, invoke _spartan from the command line with options:
$ _spartan [keywords][flags][options]
- First install the utility:
-
_keywords
- There's really only one keyword:
init
. This will run the configuration wizard, unless you also use the-y | -yes
flag to just accept the defaults and use the canned policy like this:$ _spartan init -y
OR$ _spartan init -yes
- There's really only one keyword:
-
_flags
-
-d | -default
: builds a preconfigured, default security policy andsecurity.js
. Word of warning that the default policy is fairly strict, so you may need to adjust it so it works for you -
-f | -force
: force a complete regeneration of the boilerplate code defined insecurity.js
. Typically used after making a manual adjustment to the security.json file. -
-u | -update
: updates the latest policy as defined in security.json (see notes below onsecurity.js
) -
-n | -no-overwrite
: creates a new policy andsecurity.js
file without overwriting the previous files. The filename will have the policy number appended.
-
-
_options
-
update by section : admittedly, the wizard is kind of long. If you know what section you want to update, simply append the section name to the end of the update command like this:
$ _spartan -u 'cachePolicy'
. This will take you to the portion of the questionnaire which addresses this topic. Before you ask, yes, there's a PR in the works to be able to do direct updates from the command line. -
delete
: deletes the most recent security.json AND the security.js files. It does not remove any of the dependencies frompackage.json
, unless it is run with the-force
flag like this:$ _spartan -f delete
-
set-as-default
: sets the latest policy as the default. Any future policies generated with the default option will reference this policy.
-
update by section : admittedly, the wizard is kind of long. If you know what section you want to update, simply append the section name to the end of the update command like this:
security.js
Some words about -
_updates As previously stated,
security.js
is the actual boilerplate code that is generated once you configure your security policy (security.json
). Making updates to the security policy directly will not translate to updates to the security.js file, and vice versa.- If you want policy updates to flow to the code, you'll need to run
_spartan -u [ | section you want to update]
. This will take you back into the questionnaire (or the section you specified in the command line argument). Once complete, it will completely overwritesecurity.js
with a new version reflecting the updated policy configuration. - Alternatively, you can also run
_spartan -f | -force
after updating the policy directly. _spartan will parsesecurity.json
and will overwrite the existingsecurity.js
file with a new version reflecting the most current policy.
- If you want policy updates to flow to the code, you'll need to run
EXAMPLES!
FAQ!
-
Can I write my own policy without going through the questionnaire?
Sure. Just be sure to use the common template and leave the policy number component blank.
security.js
will only be generated based upon the existing format. Generation ofsecurity.js
is an atomic process => if there's an error or typo, it will not be generated at all. If the process is successful, a new policy number will be populated in the completed security.json file. -
Where can I see errors or logs for _spartan processes?
For the time being, logs are stored in the local directory. I'll eventually do a PR to offer a config.json file where this can be user specified. In the meantime, I suggest adding
_spartan_events.log
to .gitignore -
Can I define multiple policies?
Sure. For now, _spartan will only generate
security.js
from the most recent policy (according to the spartan event logs). I have been giving some thought to adding a-r [policy_number]
option to allow _spartan to regeneratesecurity.js
based upon the reference number in each policy. - What if I want to use different modules than the ones added in during the policy spec phase? Do you boo. _spartan was developed and tested to work with a handful of specific modules with known configuration options. If you want to add/modify/delete configuration options in your app, or if you want to utilize other middleware, feel free! In this case, I would recommend disabling or removing _spartan generated methods for the purposes of code clarity. Results may vary.
-
Can I just arbitrarily change
security.json
without making any real changes to the code base? I mean, you can...but why? That kind of defeats the whole purpose. I would recommend running_spartan -f
when you're done to regenerate security.js to avoid confusion down the line. -
If I decide later on to disable certain parts of the security policy, will this also be refelected in my main code base?
Kinda.
security.js
will be regenerated and it will be missing the middleware from the disabled portions of the policy. If your code base references that missing middleware anywhere you'll end up with a breaking error. As a general rule, anything you wire up, you'll need to be able to unwire. This was a purposeful design decision to encourage people to make policy changes with care/caution - What's your problem with JWT? Not so much a problem per se, but more of a concern with the ability to easily revoke JWTs in the event something goes awry. You're far awesomer than me if you want to build and implement your own revocation scheme for JWT in your application. I'd say if your app won't be internet-facing or doesn't have any sensitive information to process or present back to users, then, sure, enjoy your JWT. I'm not planning on building any kind of support in for JWT policy configuration, though.