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).
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.
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.
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.
Only Admin can take action for provisioning the access for the Users and they can also de-provision a user.
The Spurtcommerce Platform locks the user account on some intervals. In this case, the Attacker cannot guess the user names and passwords.
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.
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.
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.
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.
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.
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.
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.
Reviews if the platform stores sensitive information on the client side. And then it also reviews if access can occur without authorization.
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.
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.
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.
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.
User cannot give access to a module by themselves and for any user, the access can be provided only the higher ranked admin users.
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.
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.
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.
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.
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.
In Spurtcommerce Project, we have used request files for each request and in the request, they can use only the respective parameters.
The platform validates each param value and sanitizes any inputs from XSS attack.
The platform does not allow some characters for some params and this has been done to restrict the attackers.
The platform validates the email body param with any Brute Force attacks so that attacker cannot include html or any script kind of tags.
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.
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.
The platform restricts the string that causes any undesired behaviour from the Platform.
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.
We have used HTTPS to review the digital certificate's cryptographic strength and validity.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Showing our platform in iframe is one of the vulnerabilities. We prevent the showing of our platform in iframes.
We store token in local storage and in server side, we use middleware to validate the token. It will not trust the client data.
We prevent the leaking of any sensitive data information from the platform.
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.
We have secured the production ready configuration in deployment and validate that all the inputs from the XSS attack.