Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Call out the security requirements in PRD like a Sample functional requirement: user needs the ability to verify their contact information before they are able to renew their membership.
Sample security consideration: users should be able to see only their own contact information and no one else’s.
This phase translates in-scope requirements into a plan of what this should look like in the actual application. Here, functional requirements typically describe what should happen, while security requirements usually focus on what shouldn’t.
Sample functional design: page should retrieve the user’s name, email, phone, and address from CUSTOMER_INFO table in the database and display it on the screen.
Sample security concern: we must verify that the user has a valid session token before retrieving information from the database. If absent, the user should be redirected to the login page.
When it’s time to actually implement the design and make it a reality, concerns usually shift to making sure the code is well-written from the security perspective. There are usually established secure coding guidelines as well as code reviews that double-check that these guidelines have been followed correctly. These code reviews can be either manual or automated using technologies such as static application security testing (SAST).
That said, modern application developers can’t be concerned only with the code they write, because the vast majority of modern applications aren’t written from scratch. Instead, developers rely on existing functionality, usually provided by free open-source components to deliver new features and therefore value to the organization as quickly as possible. In fact, 90%+ of modern deployed applications are made of these open-source components. These open-source components are usually checked using Software Composition Analysis (SCA) tools.
Secure coding guidelines, in this case, may include:
Using parameterized, read-only SQL queries to read data from the database and minimize chances that anyone can ever commandeer these queries for nefarious purposes
Validating user inputs before processing data contained in them
Sanitizing any data that’s being sent back out to the user from the database
Checking open source libraries for vulnerabilities before using them
The Verification phase is where applications go through a thorough testing cycle to ensure they meet the original design & requirements. This is also a great place to introduce automated security testing using a variety of technologies. The application is not deployed unless these tests pass. This phase often includes automated tools like CI/CD pipelines to control verification and release.
Verification at this phase may include:
Automated tests that express the critical paths of your application
Automated execution of application unit tests that verify the correctness of the underlying application
Automated deployment tools that dynamically swap in application secrets to be used in a production environment
The story doesn’t end once the application is released. In fact, vulnerabilities that slipped through the cracks may be found in the application long after it’s been released. These vulnerabilities may be in the code developers wrote but are increasingly found in the underlying open-source components that comprise an application. This leads to an increase in the number of “zero-days”—previously unknown vulnerabilities that are discovered in production by the application’s maintainers.
These vulnerabilities then need to be patched by the development team, a process that may in some cases require significant rewrites of application functionality. Vulnerabilities at this stage may also come from other sources, such as external penetration tests conducted by ethical hackers or submissions from the public through what’s known as “bug bounty” programs. Addressing these types of production issues must be planned for and accommodated in future releases.
To ensure smooth deployments and minimize potential issues, it's crucial to follow a thorough checklist. Here's a high-level overview:
Know what is going to get deployed
Excessive testing; preferably using a pipeline with automated tests
Know when is going to get deployed
Create backups
Deploy to production
Test on the live server
By adhering to this checklist, you can enhance control over deployments and reduce the likelihood of complications.
Health checks
Apps are independent
Graceful shutdown
Fault tolerance
Resources utilisation
Tagging resources
Logging
Scaling
Configuration and secrets
Namespace limits
Pod security policies
Network policies
Role-Based Access Control (RBAC) policies
Custom policies
Approved Kubernetes configuration
Below are some simplified best practices to ensure security:
Role Action mapping should be in accordance with the business requirements. No role should have access to resources that are not required by that role on UI. In the case of a CITIZEN role, extra precaution should be taken. If there is a business requirement for user-based access to entities instead of role-based access, validations should be added at the module level to verify the user id.
There is a possibility of horizontal/vertical escalation in the case of workflows. We have fixed this issue by validating the logged in user and the workflow item's owner. Allowing access if the logged-in user and the workflow owner are the same.
We use pre-signed URLs, so we cannot restrict access to the file if someone gets the URL. As a security measure, we should restrict the value of the URL validity to as minimum as possible. The value is configurable and can be overwritten in helm charts using the following property:
API’s like /user/_search which exposes the personal data of users shouldn’t be directly exposed. We have removed access to the API from UI, the user information of logged in user can be instead fetched from /user/oauth/token which is now enhanced to return the required info.
Unrestricted file upload is a serious security risk. To tackle this problem we have a bunch of security validations. The file extension, content and content type in the header are all validated. We define the allowed extensions and their corresponding content type as a map and is configurable using the following property:
Before adding endpoints in the whitelist or mixed endpoints list all security implications should be thought through, as there will be no authentication or authorisation of the request. It’s a good practice to add origin-based rate limiting to avoid DDoS attack.
The account locking mechanism is provided in the DIGIT platform and should never be disabled. It helps in mitigating brute force attacks.
All _create API’s should have some sort of rate throttling to avoid DDoS attack that can overwhelm the system. The rate-limiting can be achieved by configuring the endpoint in limiter.properties of zuul. Following is a sample configuration:
Client secrets shouldn’t be sent in Base64 encoded format from UI, only for the server to server call the secret can be sent in Authorization header in Base64 format. We have removed client secret from the Authorization header in Digit Platform
Avoid sending sensitive information in URL as a query param. Instead, it can be sent either in the request body or in headers. For example in the previous Digit version in _logout API, authToken was sent in query param as below:
The API is now enhanced to accept the authToken in Request Body as below :
Proper expiry time should be set for authToken validity. In case the authToken get’s stolen, it can be exploited only till the time the token is valid. The validity can be configured from the following two property in helm charts:
Multiple logins using the same user name and password should be avoided. Due to business requirement, we currently have not implemented this feature in DIGIT.
Errors should not expose any sensitive data or detailed error message to the end-user. Hackers can use this information to attack the system. Use of e.printStackTrace() should be avoided instead the error should be logged using logger. Always return a custom error message to the end-user.
All user inputs should be validated before storing in DB. If not done attacker could use malicious input to modify data or possibly alter control flow in unexpected ways, including arbitrary command execution. In Digit we use annotations to validate user data Following is a sample validation using annotations:
Validate any user input that is used to create an email subject line from user input. And encode special characters after proper canonicalization, and in particular, any line break (CR / LF) characters in the input, that attackers may use to inject unexpected headers in the mail message sent to the server.
Always overwrite sensitive values in application.properties during deployment. Never use hardcoded credentials. Generally, the sensitive values in application.properties will be like the DB user name and password, secrets etc. In Digit all the sensitive values are overwritten using kubernetes ConfigMaps. Following is examples of properties that we overwrite:
Make sure any sensitive information like authToken or secrets are not exposed in any configuration file.
If the format string is constructed with untrusted input, an attacker may produce unexpected application behaviour. It may cause an exception such as java.util.MissingFormatArgumentException to be thrown (which, if not cached, may lead to a denial-of-service condition), or information leak. Do not compose format strings from untrusted input. The arguments, except format string, to the formatting methods, are data and could contain format specifiers without any unexpected behaviour.
Sanitize user input before using it in HTTP parameters. Concatenating unvalidated user input into a URL can allow an attacker to override the value of a request parameter
There are two types of PRNGs: statistical and cryptographic. Statistical PRNGs provide useful statistical properties, but their output is highly predictable and form an easy to reproduce numeric stream that is unsuitable for use in cases where security depends on generated values being unpredictable. Cryptographic PRNGs address this problem by generating output that is more difficult to predict. In the latest release of Digit we have taken care of it by the following replacement:
replaced with
The use of a weak hashing algorithm could compromise the original value. For example, if an authentication system takes an incoming password and generates a hash, then compares the hash to another hash stored in the authentication database, then the ability to create a collision could allow an attacker to provide an alternate password that produces the same target hash, bypassing authentication. It is recommended to use SHA-2 instead of SHA-1.
The problem with a flawed SSL configuration is that it may allow man-in-the-middle attacks and other issues. Following is a reference implementation:
An attacker could inject line separators (CR/LF sequences) that could split the response message generated by the software into two messages. The second response is completely under the control of the attacker (intermediate web proxies may cache it), with could produce multiple conditions (web defacement, cache poisoning, cross-site scripting, or page hijacking). It is recommended to strip out any input which contains the %0d%0a URL encoded characters in HTTP request headers.
Security exceptions are related to security breaches such as denied permissions and improper use of the API. The code should not catch security exceptions except in specific cases where it may be necessary to mask some of these exceptions, for example, in the case of a log-on failure.
Not validating and normalizing the user input can lead to the execution of arbitrary code. An application’s strategy for avoiding cross-site scripting (XSS) vulnerabilities may include forbidding <script> tags in inputs. Such blacklisting mechanisms are a useful part of a security strategy, even though they are insufficient for complete input validation and sanitization. When implemented, this form of validation must be performed only after normalizing the input. We handle this by annotating all string user input field with @SafetHtml annotation
Throwing an exception from within a finally block will mask any exception which was previously thrown in the try or catch block, and the masked's exception message and stack trace will be lost.
Failure to properly close resources will result in a resource leak which could bring first the application on to their knees. Always closes any input stream in finally block.
CSRF attack forces a logged-on victim’s browser to send a request to a vulnerable web application, which then performs the chosen action on behalf of the victim. A successful CSRF exploit can compromise end user data and operation in the case of a normal user. If the targeted end user is the administrator account, this can compromise the entire web application. For this attack to be successful, the user must be logged into the application.
We have fixed these CSRF issues by adding a CSRF Filter in the security filter chain. All requests mapped pass through the csrf filter and the csrf token validation happens in the filter. All the requests except GET required to pass a csrf token.
applicationContext-security.xml
applicationSecurityContext-<modulename>.xml
ex: applicationSecurityContext-egi.xml
Cross-site scripting is a web security vulnerability that allows an attacker to compromise the interactions that users have with a vulnerable application. It allows an attacker to circumvent the same origin policy, which is designed to segregate different websites from each other.
We have added a Validation Interceptor to validate the user input for all struts requests. Used OWASP AntiSamy policy to validate the user input.
Added entity level validation annotations to validate the entities used in spring requests.
struts.xml
XSSValidator.java
The application was missing the “Secure” cookie attribute which was carrying the session information (SessionID). The Secure attribute makes sure that the cookie will only be sent with requests made over an encrypted connection and an attacker will not be able to steal cookies by sniffing.
Added the missing secure cookie attribute
Application accepts the unvalidated user input. Interpreting user-controlled instructions at run-time can allow attackers to execute malicious code.
Fixed this issue by sanitizing the user input and removed eval().
Used format specifiers (%s, %d, %c etc) while constructing format strings instead of adding using the additional operator.
Fixed this issue by using WebDataBinder.setDisallowedFields() to disallow id in request binding.
Most of the loops present in the third party (YUI) libraries. So we have not changed this.
Replaced the dangerous J2EE API with OWASP Enterprise Security API (ESAPI) equivalent APIs
pom.xml
Sanitized the user input to fix this issue.
Changed the identifiers setter to private/protected
URL Redirection to Untrusted Site ('Open Redirect') It was observed that the application redirects the user’s browser to a URL provided in a user request, without proper validation of the user input. So it is recommended not to allow external input to modify the target URL. Perform a strict validation on the external input to ensure that the final URL is valid, appropriate for the application, and authorized
Exported activity must require permissions
Activity can be exported by setting its attribute exported=true, or adding an intent-filter not setting attribute exported=false. To receive or bind them permission must be required, otherwise, any apps can access the activity
It is recommended to set attribute exported=false or remove the intent-filter as default value without the intent is considered as false.
Potential code injection via WebView.addJavaScriptInterface()
Exposing Java objects to JavaScript could have negative security implications, such as code injection (allowing access to native phone functionality like sending SMS to premium numbers, accessing account information and sensitive data, etc.) Such code injection may, for example, do something like this (to launch a system command): exposedObj.getClass().forName('java.lang.Runtime').getMethod('getRuntime', null).invoke(null, null).exec(cmd) To avoid this security issue, you may remove addJavaScriptInterface() when possible
Either
(1) remove the JavaScript/Java bridge (addJavascriptInterface) or
(2) make sure that the content loaded by WebView is really trusted (and place a suppression for violations when needed), or
(3) upgrade to API level 17 or higher and place a @JavascriptInterface annotation on allowed public methods, as in the following code
Intent Manipulation
The application allows the user input to control Intent parameters that could enable an attacker to control the behaviour of the subsequent activity If untrusted input is inserted into certain parts of an Android Intent, without proper sanitization, a malicious user or app could force, via the tainted Intent, the execution of unintended code or inject malicious data in the vulnerable app. Certain Intent properties could change the expected semantics of the Intent, like setAction(), setClass(), setClassName(), or setComponent(). If the Intent is used to start an Activity or Service, for example, the attacker may change the expected element launched, with potential nefarious consequences It is recommended to validate untrusted input that does not proceed from app-controlled resources, and in particular user interface fields and other Intents coming from other apps.
Do not release debuggable apps
It was observed that android:debuggable is set to true. Android allows the attribute android:debuggable to be set to true in the manifest so that the app can be debugged. By default this attribute is disabled, i.e., it is set to false, but it may be set to true to help with debugging during the development of the app. However, an app should never be released with this attribute set to true as it enables users to gain access to details of the app that should be kept secure. The best practice is to set android:debuggable="false">
Enabling JavaScript is not recommended WebView consumes web content that can include HTML and JavaScript from an external URL, improper use can introduce common web security issues such as cross-site-scripting (XSS, or JavaScript injection).
Android includes several mechanisms to reduce the scope of these potential issues by limiting the capability of WebView to the minimum functionality required by your application.
Do not use eval() function, for security and performance reasons It was observed that the application uses eval(code)
If the end-user has control over evaluated code (because the code is concatenated with user data), this leads to 'script injection' vulnerabilities, which could end in well-known security attacks like cross-site scripting.
It is recommended to avoid the use of eval(code).
Do not use dangerouslySetInnerHTML property in React components.
dangerouslySetInnerHTML is React’s replacement for using innerHTML in the browser DOM. In general, setting HTML from code is risky because it’s easy to inadvertently expose your users to a cross-site scripting (XSS) attack.
Avoid dangerouslySetInnerHTML, equivalent to the risky innerHTML in DOM, when possible. Try using HTML directly from React, but use dangerouslySetInnerHTML and pass an object with a __html key.
Avoid post cross-document messages with an overly permissive target origin It was observed that the cross-document messaging feature has been used. The feature allows scripts to post messages to other windows. The corresponding API allows the user to specify the origin of the target window. However, caution should be taken when specifying the target origin because an overly permissive target origin will allow malicious script to communicate with the victim window in an inappropriate way.
Always specify an exact target origin, not *, when you use postMessage to send data to other windows. A malicious site can change the location of the window without your knowledge, and therefore it can intercept the data sent using postMessage.
We have Removed the instance as it was not required.
Potential infinite loops The application executing infinite loops using user inputs. would lead to denial of service.
It Is recommended to a proper termination condition for every lo0ps
Never use JavaScript 'history' object or navigation-based positioning functions Using 'history' (window.history, self.history) or navigation-based positioning functions (window.back(), window.forward()) is a bad practice for different reasons: * POST: If a visited page was generated with POST, the browser will emit a warning if the submitted data is not encoded in the URL. * PRIVACY: No application should know which pages a user visited (browsers will emit a security alert and block access). * POOR NAVIGATION LOGIC: The exact page sequence taken by users may not match programmer expectations
It is recommended not to use the navigation history.
The APIs developed on DIGIT adhere to specific conventions and principles. Below are the dos and don'ts to be observed when following these API principles.
Always define the Yaml for your APIs as the first thing using Open API 3 Standard ().
APIs path should be standardised as follows:
/{service}/{entity}/{version}/_create: This endpoint should be used to create the entity.
/{service}/{entity}/{version}/_update: This endpoint should be used to edit an entity which is already existing.
/{service}/{entity}/{version}/_search: This endpoint should be used to provide a search on the entity based on certain criteria.
/{service}/{entity}/{version}/_count: This endpoint should be provided to give a count of entities that match the given search criteria.
Always use POST for each of the endpoints.
Take most search parameters in the POST body only.
If query params for search need to be supported then make sure to have the same parameters in the POST body also and the POST body should take priority over query params.
Provide additional detail for objects in _create and _update APIs so that custom requirements can use these fields.
Each API should have a object in the request body at the top level.
Each API should have a object in the response body at the top level.
Mandatory fields should be the minimum for the APIs.
minLength and maxLength should be defined for each attribute.
Read-only fields should be called out.
Use common models already available in the platform in your APIs. Example -
(Citizen/ Employee/ Owner)
(Response sent in case of errors)
TODO: Add all the models here
For receiving files in an API, do not use binary file data. Instead, accept the file store ids.
If there is only one file to be uploaded and no persistence is needed, and no additional JSON data is to be posted, you can consider using direct file upload instead of using filestore id.
POJO
Validate string sizes.
Use regex validations when applicable.
Apply @SafeHtml or custom annotations to prevent HTML code in string fields.
File Upload
Rename files before storage.
Avoid storing files in the application folder.
Whitelist only required file extensions.
Check the file's magic number using a library like Apache Tika.
API
Implement rate throttling on _create API.
Return results in a paginated manner for _search API.
Carefully whitelist APIs to avoid security loopholes.
Apply IP-based throttling on whitelisted APIs to prevent DDoS attacks.
Verify role-action mapping, especially for the CITIZEN role, to ensure only necessary APIs are accessible.
Avoid sending sensitive information in URLs; use request bodies or headers instead.
Coding Practices
Proper error handling, avoid returning complete stack traces.
Use strong hashing algorithms like SHA-2 for generating hashes.
Avoid capturing Java.Lang Security Exception.
Do not throw exceptions in finally blocks.
Always close input and output resources in finally blocks.
Avoid creating pathnames directly from external input.
Check for potential infinite loops and avoid executing loops directly with user input.
Prevent SQL injection by using prepared statements instead of string queries.
Use cryptographic PRNG instead of standard pseudo-random generators.
Avoid hardcoding sensitive or environment-dependent properties like DB host and password.
Refrain from logging sensitive information or exposing it through error messages.
Do not compare class objects using getName() or getSimpleName() methods.
Ensure the setter method for identifier properties (id or composite-id) is private.
Do not allow external input to control resource identifiers.
Checklist for a better web application performance
Performance is crucial in today's web applications. A slow app feels buggy to the users and makes them flee it. Although performance is such an important topic, there are so many optimization vectors that it's easy to forget some of them. The intent of this checklist is to gather performance practices to apply when developing a web application.
While we apply these practices, we should always keep the following rules in mind:
Don't optimize too early
Don't let performance ruin productivity
Always check an optimization is efficient by measuring performance before and after it
Images represent in average ~60% of a page's weight, thus it's an important part to optimize.
We can use prefetching to prepare the browser to next requests and make them faster or even instant. This article is a few old but explains well the following techniques.
Ideally the critical code should fit in 14KB in order to be server in the first TCP roundtrip (why 14KB?). These techniques help to achieve this goal.
User-perceived performance is often disregarded but can be more important than actual performance. These techniques allow us to improve it.
Provide batch queries/transactions instead of making the client send multiple requests
Identify & optimize slow resources
Parallelize slow tasks
Use relevant data structures
Don't overuse serialization
Generate static content when deploying so that it will be computed only once
If possible, use jemalloc to improve memory allocation
Application security checklist by various functions
Application security is a critical topic. Being a good engineer requires being aware of Application security best practices. We should practice defensive programming and ensure run security checks much earlier and more frequently during every phase of the software development. The earlier we catch vulnerabilities, the less dramatic and expensive those violations are to resolve. Waiting until release will just leave us nervous and unprepared. Delivering security alongside the continuous delivery of software, we'll identify security problems before they become hopelessly entangled in the application and therefore more difficult, and costly, to resolve.
Teams should ensure the following checks to deliver security.
Injecting Security in the design phase means addressing design decisions that take into account the perspective of an attacker that is trying to breach weaknesses and compromise the confidentiality, integrity and other important security aspects of your software.
Logging
A successful web application security strategy fundamentally begins with an understanding of the interactions between the web server, users, and applications. While application deployment platforms vary, key vulnerabilities in infrastructure configuration act as a common weak link for threat actors to initiate an attack.
Some key application security information-gathering activities include:
Identify technologies used
Identify user roles
Identify application entry points
Identify client-side code
Identify multiple versions/channels (e.g. web, mobile web, mobile app, web services)
Identify co-hosted and related applications
Identify all hostnames and ports
Identify third-party hosted content
A web server ecosystem is intrinsically complex with highly connected, heterogeneous services and components working together. Reviewing and managing the configuration of the server is, as a result, a very crucial aspect for maintaining robust security across multiple layers of an application.
Securing various configuration items of an application involves:
Check for commonly used application and administrative URLs
Check for old, backup and unreferenced files
Check HTTP methods supported and Cross Site Tracing (XST)
Test file extensions handling
Test for security HTTP headers (e.g. CSP, X-Frame-Options, HSTS)
Test for policies (e.g. Flash, Silverlight, robots)
Test for non-production data in live environment, and vice-versa
Check for sensitive data in client-side code (e.g. API keys, credentials)
Check SSL Version, Algorithms, Key length
Check for Digital Certificate Validity (Duration, Signature and CN)
Check credentials only delivered over HTTPS
Check that the login form is delivered over HTTPS
Check session tokens only delivered over HTTPS
Check if HTTP Strict Transport Security (HSTS) in use
Test for user enumeration
Test for authentication bypass
Test for bruteforce protection
Test password quality rules
Test remember me functionality
Test for autocomplete on password forms/input
Test password reset and/or recovery
Test password change process
Test CAPTCHA
Test multi-factor authentication
Test for logout functionality presence
Test for cache management on HTTP (eg Pragma, Expires, Max-age)
Test for default logins
Test for user-accessible authentication history
Test for out-of-channel notification of account lockouts and successful password changes
Test for consistent authentication across applications with shared authentication schema / SSO
Once a user is authenticated, their interaction with the server is managed within a session. Improperly managed sessions open doors for attackers to compromise access mechanisms by assuming those to be identities of legitimate users. More so, such compromised accesses are often taken advantage of by attack vectors that escalate privileges and penetrate deeper into the system. To avoid vulnerabilities within a session, the following processes are recommended to be tested as a best practice:
Establish how session management is handled in the application (eg, tokens in cookies, token in URL)
Check session tokens for cookie flags (httpOnly and secure)
Check session cookie scope (path and domain)
Check session cookie duration (expires and max-age)
Check session termination after a maximum lifetime
Check session termination after a relative timeout
Check session termination after logout
Test to see if users can have multiple simultaneous sessions
Test session cookies for randomness
Confirm that new session tokens are issued on login, role change and logout
Test for consistent session management across applications with shared session management
Test for session puzzling
Test for CSRF and clickjacking
Test for path traversal
Test for bypassing authorization schema
Test for vertical Access control problems (a.k.a. Privilege Escalation)
Test for horizontal Access control problems (between two users at the same privilege level)
Test for missing authorization
Test for Reflected Cross Site Scripting
Test for Stored Cross Site Scripting
Test for DOM based Cross Site Scripting
Test for Cross Site Flashing
Test for HTML Injection
Test for SQL Injection
Test for LDAP Injection
Test for ORM Injection
Test for XML Injection
Test for XXE Injection
Test for SSI Injection
Test for XPath Injection
Test for XQuery Injection
Test for IMAP/SMTP Injection
Test for Code Injection
Test for Expression Language Injection
Test for Command Injection
Test for Overflow (Stack, Heap and Integer)
Test for Format String
Test for incubated vulnerabilities
Test for HTTP Splitting/Smuggling
Test for HTTP Verb Tampering
Test for Open Redirection
Test for Local File Inclusion
Test for Remote File Inclusion
Compare client-side and server-side validation rules
Test for NoSQL injection
Test for HTTP parameter pollution
Test for auto-binding
Test for Mass Assignment
Test for NULL/Invalid Session Cookie
Test for anti-automation
Test for account lockout
Test for HTTP protocol DoS
Test for SQL wildcard DoS
Hackers mostly leverage an application’s original programmed flow to orchestrate breaches and penetration attacks. As a result, it is recommended to assess the business and application’s configuration to identify vulnerabilities in code or business logic that could be used for potential exploits.
Test for feature misuse
Test for lack of non-repudiation
Test for trust relationships
Test for integrity of data
Test segregation of duties
Cryptography ensures the secure exchange of information by using algorithms that transform human-readable data into a ciphertext-encrypted output. While doing so, the process establishes trust between the web server and network entities using security keys, making it an important mechanism for maintaining application security. Testing cryptography for maintaining application security involves:
Check if the data which should be encrypted is not
Check for wrong algorithms usage depending on the context
Check for weak algorithms usage
Check for proper use of salting
Check for randomness functions
Test that acceptable file types are whitelisted
Test that file size limits, upload frequency and total file counts are defined and are enforced
Test that file contents match the defined file type
Test that all file uploads have Anti-Virus scanning in-place.
Test that unsafe filenames are sanitised
Test that uploaded files are not directly accessible within the web root
Test that uploaded files are not served on the same hostname/port
Test that files and other media are integrated with the authentication and authorisation schemas
Test for known vulnerabilities and configuration issues on the Web Server and Web Application
Test for default or guessable password
Test for non-production data in a live environment, and vice-versa
Test for Injection vulnerabilities
Test for Buffer Overflows
Test for Insecure Cryptographic Storage
Test for Insufficient Transport Layer Protection
Test for Improper Error Handling
Test for all vulnerabilities with a CVSS v2 score > 4.0
Test for Authentication and Authorization issues
Test for CSRF
Test Web Messaging
Test for Web Storage SQL injection
Check CORS implementation
Check Offline Web Application
Application Access