Data security is an integrated part of our R&D 

We have tested Workspace against multiple known security issues and implemented protection for these issues. Instead of solely trusting our own judgment, we have also evaluated and scanned our software with an independent security consulting agency.

Data security issues are an integrated part of our software development process. Also security evaluations are a continuous process and we do a lot of co-operation with security experts to ensure that our applications and deployments are as secure as possible. Two members of our R&D team hold CISSP certifications.

The following issues, among others, have been addressed in the development of Workspace:

Session management

Session identifiers are kept in cookies

Session identifiers are always transferred via cookies to prevent them leaking via referrer urls or bookmarks.

Secure session identifiers

Workspace doesn't generate its own session identifiers but delegates that responsibility to its application server. Although the solutions security then depends on the application server's security, it usually provides stronger session identifiers than homegrown solutions because application servers go through much scrutiny by their large user base.

Authentication and authorization

User and Role based authorization

Workspace uses a popular and proven Role based authorization scheme.

Single point of entry

The Workspace Administration Interface authentication implements a single point of entry which enables easier evaluation of authentication's correctness.

Password based authentication

Users are authenticated via passwords.

Optional IP restrictions support

Access to the Administration Interface and to the Webshop can also be restricted via IP restrictions.

Privacy considerations

Caching disabled

Pages served by Workspace have http-headers that tell browsers to disable caching of the pages. This somewhat decreases the risk of having private pages stored on a public computer's browser cache.

Passwords aren't stored, only their checksums

Workspace doesn't store the user's password. It only stores an MD5 checksum of the password that can be used to check that the user has given the same password as previously. The stored checksum generally cannot be used to retrieve or reassemble the password.

Credit card information is not available

Workspace's online payment system integrations have been implemented in ways that the buyer's private payment information (credit card numbers etc) is not available to Workspace at any time. The buyer always supplies this kind of information directly to the payment solution.

Platform security support

SSL enabling

SSL should always be enabled for the Administration Interface. See your application server instructions for configuring SSL support. We also recommend using SSL for the webshop too.

Java Sandbox and Workspace security policy

Java Security policy descriptions can be created to externally restrict Workspace's access to the system. Note that general system security issues should also be addressed, such as updating security fixes, auditing user access, using a well-configured firewall and secure passwords, checking log files, etc.

Other issues

Cross-site scripting prevention

Cross-site scripting has been identified as a security threat and Workspace has gone through multiple evaluations regarding cross-site scripting in different situations. For example all information given by the user is escaped in order to prevent hijacking of the Administration Interface.

Buffer overflows

Buffer overflows are not likely to happen on the Java platform and Workspace doesn't include any native extensions that would increase the likelihood of buffer overflows.

SQL Injection

SQL Injection has also been identified as a security threat and it is prevented systematically throughout the software, by using PreparedStatements (or an equal method) in most places and by escaping input manually with a library method where the previously mentioned techniques aren't used but user input is involved.