Spurtcommerce follows the OWASP principles for its inbuilt Security.

Spurtcommerce team has implemented a wide range of security rules that is established by the Industry's leading research and standards on security vulnerabilities - OWASP (Open Web Application Security Project).

Identity Management Testing

In eCommerce and online retail platforms, Identity Management plays a vital role and it needs to be seamless and secure for identifying the User and their role and to ensure that they can only access those customer data or information that they need or they are entitled to. In Spurtcommerce, whenever a new user comes into picture, all the required protocol and rules are being followed. You may have a look at the different testing mechanisms pertaining to Identity Management that have been followed and are being passed.

Test Role Definitions - WSTG-IDNT-01

In our eCommerce project, the roles and permissions to that role are properly defined. A user can only access or will have permission to only access the modules for which they have been given the access for.

Test User Registration Process - WSTG-IDNT-02

We have used email as the identity for the users. Users can register with basic inputs and email will be unique for each user. The same email Id cannot be used for multiple user accounts.

Test Account Provisioning Process - WSTG-IDNT-03

Only Admin can take action for provisioning the access for the Users and they can also de-provision a user.

Testing for Account Enumeration and Guessable User Account - WSTG-IDNT-04

The Spurtcommerce Platform locks the user account on some intervals. In this case, the Attacker cannot guess the user names and passwords.

Testing for Weak or unenforced username policy - WSTG-IDNT-05

In this eCommerce project, we are not providing any error message related to the guessable account names and we use only the unique email as the user name.

Authentication Testing

User Authentication is an important aspect in eCommerce. One of the most compelling reasons to test from an authenticated user's perspective is that some vulnerabilities are exploitable without credentials but are only discoverable with credentials. Without authentication testing a serious external weakness which would allow user impersonation would go unnoticed. You may have a look at the details of the principles and rules that authenticates the Users for their genuiness in our Spurtcommerce project.

Testing for Credentials Transported over an Encrypted Channel - WSTG-ATHN-01

Sensitive data are protected when it is transmitted through the network and we have used HTTPs for the platform and redirect any HTTP requests to HTTPS.

Testing for Default Credentials - WSTG-ATHN-02

We have configured the platform to have user passwords non-guessable. The user cannot give a password that fully or partially replicates the user names and the passwords must have special characters, numbers and upper cases.

Testing for Weak Lock Out Mechanism - WSTG-ATHN-03

Evaluates the account lockout mechanism’s. ability to mitigate brute force password guessing. Then it evaluates the unlock mechanism's resistance to unauthorized account unlocking. After 5 successful attempts, we have configured for the lock of user account for some time and this has been done in order to prevent attackers guess passwords.

Testing for Bypassing Authentication Schema - WSTG-ATHN-04

Ensures that authentication is applied across all services that require it. Our platform authenticates the user in each request by the use of middleware. Any unauthorised person will not be able to access any request without passing through the authentication.

Testing for Vulnerable Remember Password - WSTG-ATHN-05

Validates that the generated session is managed securely and do not put the user's credentials in danger. And, the password does not save in the browser.

Testing for Browser Cache Weaknesses - WSTG-ATHN-06

Reviews if the platform stores sensitive information on the client side. And then it also reviews if access can occur without authorization.

Testing for Weak Password Policy - WSTG-ATHN-07

Determines the resistance of the platform against brute force password guessing using available password dictionaries by evaluating the length, complexity, reuse, and aging requirements of passwords. We have protected the platform by non-guessable passwords.

Testing for Weak Password Change or Reset Functionalities - WSTG-ATHN-09

For reset passwords, the platform sends the reset password link to registered email. The registered user will click on the link and reset the password as per the password policy.

Authorization Testing

User authorization is another aspect that is highly significant in eCommerce portals. In Spurtcommerce we have implemented the right mechanisms, where Users can access only those modules for which they have the permission. The permissions are denied if they try to access a module by way of a URL. So, attackers cannot retrieve any user records for which they do not hold the right.

Testing for Bypassing Authorization Schema - WSTG-ATHZ-02

User can access only their accessible modules. They cannot access other modules even if they know the URLs through which the module can be accessed. This has been done with a middleware that validates the user and the permissions they have.

Testing for Privilege Escalation - WSTG-ATHZ-03

User cannot give access to a module by themselves and for any user, the access can be provided only the higher ranked admin users.

Testing for Insecure Direct Object References - WSTG-ATHZ-04

Identifies points where object references may occur. Also, assesses the access control measures and if they're vulnerable to IDOR. The platform validates the request and checks the database and verifies the data with the user. So, attackers or hackers cannot retrieve the other user records.

Session Management Testing

The implementation of session tokens for Users of eCommerce portal is highly important. In Spurtcommerce, we have implemented the session management, where tokens authenticate the Users and these tokens are encrypted. You may have a look at the details of the process that we have followed in this regard.

Testing for Session Management Schema - WSTG-SESS-01

The platform gathers session tokens for the same user and for different users where ever possible. In this eCommerce project, we have introduced tokens for authentications and the tokens created will be unique for each user and the tokens that gets created will also be encrypted.

Testing for Logout Functionality - WSTG-SESS-06

It assesses the logout UI. It then analyses the session timeout and if the session is properly killed after logout. The platform saves the created token in the database and in every request, the system validates if the token exists in database. If not, the request gets returned followed by an error message. Then during logout, the token gets deleted from the database.

Data Validation Testing

A thorough data validation is an absolute necessity in eCommerce projects. In Spurtcommerce, we have followed the important standards for data validation by implementing the process for elimination of in appropriate data or codes and the request params. This is very important to prevent any vulnerabilities and unnecessary entry of irrelevant data. You may view the details of the process that we have implemented for data validation in Spurtcommerce.

Testing for HTTP Parameter Pollution - WSTG-INPV-04

In Spurtcommerce Project, we have used request files for each request and in the request, they can use only the respective parameters.

Testing for SQL Injection - WSTG-INPV-05

The platform validates each param value and sanitizes any inputs from XSS attack.

Testing for SSI Injection - WSTG-INPV-08

The platform does not allow some characters for some params and this has been done to restrict the attackers.

Testing for IMAP SMTP Injection - WSTG-INPV-10

The platform validates the email body param with any Brute Force attacks so that attacker cannot include html or any script kind of tags.

Testing for Code Injection - WSTG-INPV-11

The platform also validates the request param, checks if it has the code in params. If the code exists, then it returns an error message.

Testing for Command Injection - WSTG-INPV-12

The Platform validates the request param, checks if it has the command line code in params. If it exists, then it returns with an error message.

Testing for Format String Injection - WSTG-INPV-13

The platform restricts the string that causes any undesired behaviour from the Platform.

Testing for Server-side Template Injection - WSTG-INPV-18

In the platform, we have used ejs template in the server side. This restricts the native template syntax in the request params.


In eCommerce, to avoid cart abandonment, it is important that we have one click checkout and other such features. However, these features have a risk of data breach and easy access to customer financial data. So, encryption of user tokens plays a highly significant role. In Spurtcommerce, we have used HTTPS to avoid sensitive data transmission and for any such information encryption is been made a mandate to prevent all possible data attacks and vulnerabilities.

Testing for Weak Transport Layer Security - WSTG-CRYP-01

We have used HTTPS to review the digital certificate's cryptographic strength and validity.

Testing for Sensitive Information Sent via Unencrypted Channels - WSTG-CRYP-03

We have used HTTPS to fully avoid the transmission of any sensitive information through the channels and the platform assesses the privacy and security of channels used in encryption format.

Testing for Weak Encryption - WSTG-CRYP-04

For any sensitive information, the platform generates the AES encryption crypto. This is a 64-character secret key that is highly secure and prevents any attacks.

Business Logic Testing

In Spurtcommerce, all the business logic validations are performed in server-side API only. With the use of ACL, each action on the platform is recorded and we have made sure that every key action follows a step-by-step flow in the platform. Also, we have configured the system for non-acceptance of files with extensions that can possibly pass-through irrelevant code or data into the system.

Test Business Logic Data Validation - WSTG-BUSL-01

We have made sure that all the business logic validations will be performed from the back end and our system never trusts the user data.

Test Ability to Forge Requests - WSTG-BUSL-02

We have made sure that hidden data validations are also performed in the back end and also the platform will be prevented from the forge requests.

Test Integrity Checks - WSTG-BUSL-03

We have used ACL and we also audit each action performed in our platform. This can be seen by the Admin and the admin can see full report on the actions made by each user and when (exact time) such an action was performed.

Testing for the Circumvention of Work Flows - WSTG-BUSL-06

We have also implemented a step-by-step flow in the platform. Only after the successful completion of parent flows, the remaining subsequent flows can be performed.

Test Upload of Unexpected File Types - WSTG-BUSL-08

We have allowed some expected file types only for the upload of documents and the platform restricts the files with the extensions of .php,. jsp and .aspx.

Test Upload of Malicious Files - WSTG-BUSL-09

Only these files with extensions of - pdf, xlsx, doc and docx will be allowed for upload and rest all other files with other extensions gets restricted.

Client-Side Testing

In Spurtcommerce, we have implemented the solutions for all possible vulnerabilities that can occur through Client side and may lead to the leakage of any sensitive information. In eCommerce, this is important as there are high chances of the Users trying to imitate the URLs to fetch data for which they do not have the right. With middleware to validate the token, the system does not trust any data from the Client end.

Testing for Client-Side URL Redirect - WSTG-CLNT-04

In the Platform, we redirect the trusted URL only from our back-end response and we do not redirect any URL from the system’s front end.

Testing for CSS Injection - WSTG-CLNT-05

Showing CSS file names from view page source is one of the vulnerabilities. Our Front end that has been built on Angular changes the CSS name and replaces the names with unique names which are non-guessable.

Testing for Clickjacking - WSTG-CLNT-09

Showing our platform in iframe is one of the vulnerabilities. We prevent the showing of our platform in iframes.

Testing Browser Storage - WSTG-CLNT-12

We store token in local storage and in server side, we use middleware to validate the token. It will not trust the client data.

Testing for Cross Site Script Inclusion - WSTG-CLNT-13

We prevent the leaking of any sensitive data information from the platform.

API Testing

Our eCommerce platform validates that all the security standards and testing is satisfied and through use of Swagger with proper synchronization between Server side and Client side with REST API documentation.

Testing GraphQL - WSTG-APIT-01

We have secured the production ready configuration in deployment and validate that all the inputs from the XSS attack.


Last updated