rest-protector
v0.0.1
Published
Rest standard protection using validations, header controls and other things at a middleware format
Downloads
1
Readme
Actually in development, some of the middlewares have been added and can be used as it. Some tests will be added later.
Securing REST API from common exploits using Express 4.x middleware
According to : Owasp
Authentication
Use statelessness as possible and use protocol like OAuth2.0 through passport and oauth2orize or neither node-oauth2-server.
Whitelist allowable methods
REST API allows users to make many HTTP request with many verbs. Here's a list of all the HTTP verbs. This library allows you to restrict in a first time the global verbs allowed using this middleware :
app.use(rp.whiteListVerbs(['get','post','put','delete']));
Validate incoming content-types
"When POSTing or PUTting new data, the client will specify the Content-Type (e.g. application/xml or application/json) of the incoming data. The server should never assume the Content-Type; it should always check that the Content-Type header and the content are the same type. A lack of Content-Type header or an unexpected Content-Type header should result in the server rejecting the content with a 406 Not Acceptable response."
app.use(rp.allowRequestContentType(['application/json']));
Validate response types
"It is common for REST services to allow multiple response types (e.g. application/xml or application/json, and the client specifies the preferred order of response types by the Accept header in the request. Do NOT simply copy the Accept header to the Content-type header of the response. Reject the request (ideally with a 406 Not Acceptable response) if the Accept header does not specifically contain one of the allowable types.
Because there are many MIME types for the typical response types, it's important to document for clients specifically which MIME types should be used."
app.use(rp.allowResponseType(['text/html']));
#Send security headers
"To make sure the content of a given resources is interpreted correctly by the browser, the server should always send the Content-Type header with the correct Content-Type, and preferably the Content-Type header should include a charset. The server should also send an X-Content-Type-Options: nosniff to make sure the browser does not try to detect a different Content-Type than what is actually sent (can lead to XSS).
Additionally the client should send an X-Frame-Options: deny to protect against drag'n drop clickjacking attacks in older browsers."
app.use(rp.applyNoSniff());
app.use(rp.controlXFrameOptionDenied());