Security in Akara

Akara is a platform to facilitate RESTful services, so for the most part its inherent security issues are the same as those associated with REST architecture overall. Of course service implementations can and will introduce all manner of security issues, but this discussion focuses on matters relevant to Akara's core architecture, and security support Akara provides.

Security problems from REST anti-patterns

Most of the potential for security of REST lies in its simplicity, but this is does not always obtain in practice. For example the idea that GETs are "safe" (side effect free) is often violated by the likes of parameter-driven GET requests that modify or even resources. Akara seeks to provide enough tools to the developer to avoid this anti-pattern so that simple but effective coarse-gained security can be applied at the HTTP method level.

See also: slide 27 of XTECH07

Tainted input

Common attacks using tainted input include SQL and XPath injection, denial DOS from oversized parameters, the "billion laughs" attack from format conventions such as XML which can trigger cascading inputs, etc.

All these issues point to a single lesson: know where data is coming into your service, and in what cases this data might be coming from sources outside your close control.

Akara emphasizes identifying all the various data sources into a system, and the declaration of rules for these data sources. This can be done imperatively, but Akara supports a declarative style. One of the less obvious benefits of this declarative approach is that it serves as a flag for developers and maintainers of the system as to the data paths in the system, making it a bit easier to track how changes affect security.

See also: slide of XTECH07

HTTP Parameter Pollution

Akara does provide basic protection against HTTP Parameter Pollution. The @simple_service decorator by default forbids duplicated GET parameters.

The URI Jail

Similar to the concept of a chroot jail, Akara supports the concept of a URI policy manager. You can easily create a URI handler that allows you to register simple rules for URIs whose invocation is permitted. You could, for example limit to a set of base URIs, or you could set a policy to disable recursive redirects or or abusive patterns.


The ability to audit service interactions is an important part of security, which Akara, like many other server platforms supports with logging tools that capture protocol basics and can be extended with information in the application space.

Protocol-level security

In general Akara builds on other components and avoids reinventing wheels for protocol level security. This is a complex topic which includes:

Cross-site scripting attacks (XSS)

XSS attacks are generally a question of what script is applied by the client, and so not directly a matter for the Akara server.

Notes on application-level security

application-level security is beyond the scope of this document, but here are a few useful pointers

Amazon's security model is often praised as a good model for apps built on REST



Unfortunately much discussion of security in REST focuses on SOAP vs REST rather than fresh, focused coverage.

In the value of REST's transparency: "A network admin [of a SOAP service] just sees POSTs and cannot understand the purpose of the traffic without looking into the SOAP messages themselves"

Potential issues

Akara/Security (last edited 2010-03-23 06:21:24 by UcheOgbuji)