Authoring Secure Web Apps

Most of the potential risk associated with deploying web apps comes from the code in each app. By limiting the features that your app uses and by following the secure coding practices listed here, you can reduce the potential risk to your applications.

Authentication and Authorization

If your app requires access to sensitive data or performs potentially dangerous actions, you can consider implementing your own authentication and authorization schemes. Consult your network security group for advice.

Store Secret Keys in Vault

You can remove sensitive information, such as passwords, from code by storing secrets in your MATLAB^® vault. For information on using secrets in deployment, see Handle Sensitive Information in Deployed Applications.

The MATLAB Web App Server™ provides functionality to define access control rules that enable authenticated users to retrieve secrets from the server's vault. For information about enabling secrets access control, see Control Secrets Access in MATLAB Web App Server (MATLAB Web App Server).

Do Not Call `eval()`

The MATLAB eval() function turns text strings into commands. This powerful function allows users to execute arbitrary MATLAB code. This code can, in turn, enable execution of any installed program that is available to the low-privileged user or access to any file or data that the low-privileged users has access to. Applications created for web deployment and access must not contain calls to eval(). See Alternatives to the eval Function for ways to eliminate eval() from your web app code. Relying on input sanitization can help mitigate the risk of any indirect calls to eval(). See Sanitize User Input (MATLAB Web App Server).

Limit Free-Text User Input

Use menus, sliders, dials, and buttons instead of editable text fields in your app user interface. In addition to providing a better user experience, this practice limits the types of input users can provide, and the risks such inputs might introduce.

Sanitize User Input

To a security expert, user supplied data is considered untrusted because user input is a common attack vector for hackers. If your app must accept free-text input, the app must carefully examine the input for potential code injection attacks—text that contains special characters that coerce the app to interpret the input as commands rather than data.

In MATLAB, code injection attacks are most likely to be directed against XML, JSON, SQL, and other similar types of structured input. If your app accepts structured input, consult your IT or security group for suggestions on how to sanitize that input. It is never a good idea to allow the user to directly enter any type of code (such as MATLAB, Java^®, or JavaScript^®) for immediate evaluation.

Sanitize Data Read from Files

Reading data from files exposes the app to the same types of risk as collecting interactive user input. The same countermeasures apply. Also, you can protect read-only data files from tampering by a cryptographically secure hashing algorithm to digitally fingerprint files.

Minimize File System Write Operations

Limiting your application to read-only access greatly reduces the potential risk associated with your application. If you must write to the file system, remember that the server runs multiple copies of your application simultaneously if multiple users access it at the same time. You must manage simultaneous writes either through the use of runtime-generated unique file names or the use of a database that can typically handle multiple simultaneous accesses. If simultaneous writes are not properly managed, data corruption may occur.

Verify Trustworthiness of Third-Party Code

If your app includes MATLAB files, shared libraries, Java classes, or any other type of code developed by a third party, you must make sure that code is free of viruses, worms, Trojan horses, and other web-based attack and infiltration vectors. You can discuss this issue with the author of the code and your IT and security staff. In the case of binaries or Java classes, consider running a virus scanner or other security software on the code before including it in your deployed app.

Reduce Exposure Level

One way to reduce exposure is to limit the time that the app is running to only those times when it is needed. For example, do not run it continuously from your desktop.