Secure Coding Guidelines

Contents

Overview

Although using APIs are useful and convenient, be aware of the below risks when coding:

  • security issues may arise as a result of the code
  • the kintone.com service may not function appropriately as a result of the code

In this article, we will explain important points when programming with the API.

Prevent Cross-Site Scripting (XSS) and CSS Injection

Cross-Site Scripting (XSS) is a security vulnerability that enables attackers to inject malicious scripts into a website.
Similar to XSS, CSS Injection is a security vulnerability that enables attackers to inject malicious CSS into a website.
These scripts are executed within the browsers of website visitors, often without their knowledge or consent.

Possible threats

Programs with XSS vulnerability or CSS Injection can lead to the following threats:

  • data lying in Kintone can be stolen
  • fake sites may be displayed
  • malicious cookies may be stored in the web browser

Sample code with Vulnerability

1
2
3
const text1 = document.getElementById('text1');
const div1 = document.getElementById('div1');
div1.innerHTML = '<input type="text" value="' + text1.value + '" />';

In this code, a text box is created from the value in text1.
A code unintended by the code creator can run by placing the below code for text1.

1
"onclick="alert(1)

Preventing XSS

Escape every outputted element

Strings that are passed on from external programs, and special characters (< , > , " ) are to be escaped. You will need to have some knowledge on escaping HTML elements, but we recommend you to avoid dynamically creating HTML contents with the use of document.write and innerHTML. You can prevent common XSS though by using innerText instead of innerHTML.

Limit URL outputs to "http://" or "https://"

Dynamically creating href attributes (for a tags) or src attributes (for img tags) from external inputs has the risk of embedding of strings that begin with JavaScript:. To prevent this, limit outputs of URLs to those that begin with http:// or https://.

Avoid creating elements based on external input values

Here is a sample code that you should not run.

1
2
3
4
5
6
7
const tag = document.createElement('script');

// Don't to the following
tag.innerHTML = untrusted;

// Use innerText
tag.innerText = untrusted;
Don't load JavaScript files and CSS files that are on untrusted external sites

There's a risk that the contents of the file that you are loading could be changed unexpectedly one day to a program that steals your information. Make sure that you can trust the site that you are loading your script from.

Use HTTPS

Services on kintone.com use HTTPS to encrypt communication via the web broswer.
When connecting with external systems, make sure to use APIs that use HTTPS.

Store Authentication and Authorization Information Appropriately

When integrating with external services, authentication and authorization information for external services must be stored somewhere.
Considering the impact of any leakage of such information, carefully decide where the authentication/authorization information should be stored. Also, limit the scope of disclosure of the authentication/authorization information.
In particular, JavaScript customization tends to store authentication/authorization information in locations where general users can view it.

Examples of Authentication/Authorization Information

  • Passwords
  • API keys
  • OAuth client secrets and access tokens

Where to Store Authentication/Authorization Information

This section introduces the following storage locations:

  • Recommended locations: Storage locations that can only be viewed by Administrators
  • Inadvisable locations: Storage locations that can be viewed by general users

The following information is for reference only. Please carefully consider the appropriate storage locations, taking into account the consequences of security leaks.

The proxy functions for plug-in customizations limit the scope of disclosure of authentication/authorization information, to users with Administrator permissions for Apps.
HttpOnly Cookies prevent access from JavaScript.

Inadvisable storage locations

Web Storage, which is often used to store information, can be accessed from any JavaScript code.
Similarly, Kintone plugin settings and non-HttpOnly cookies can also be accessed via JavaScript.
Therefore, there is a possibility that authentication/authorization information can be misused, for example, if a malicious site is accessed.

Store Data Appropriately

Personal and confidential information can be retrieved from data lying on kintone.com. If you are to save these information on an external application, design and operate the system with great caution so as not to leak private information.
Especially, please do not hard code important data such as passwords into your program.

Other Cautions when using JavaScript Customizations

Cross Domain Restrictions

Due to cross domain restrictions, communication between kintone.com and external sites using XHR(XMLHttpRequest) cannot be run. The Access-Control-Allow-Origin header cannot be added.

Retrieving Cookies via JavaScript

As cookies from kintone.com have Httponly attributes, these cookies cannot be retrieved using JavaScript.

Redirecting to External Sites

If the URL passed on to the following objects are dynamically created from external input values, run a check on the created URL to see if it is in your intended format:

  • location.href
  • document.location
  • window.open

Using the "strict mode"

Using the JavaScript's strict mode will prevent miscoding and will make your code more secure. For details on strict mode, refer to the MDN document (External link) .

Main features of the strict mode:

  • values can only be placed into declared variables

  • the scope of the variables declared inside the eval() function is limited within that function.

  • arguments.calee is not supported

    1
    2
    
    'use strict';
    mistypedVaraible = 17; // throws a ReferenceError