Product Updates

Your sensitive information deserves the utmost protection, and we're excited to announce a significant update to address potential data exposure risks in DatoCMS projects.

The problem

Previously, if you had an API token with limited permissions and made a GraphQL introspection query to our Content Delivery API, you could inadvertently reveal sensitive project details beyond the token's scope. This vulnerability could expose private information such as model names, fields, and their interconnections.

To further illustrate the issue and the impact of the update, here's an example:

{
  blackFridayOffer {
    perOrderDiscount
  }
}

Let's say you have an API token that only has permissions to view the "blog articles" model in your DatoCMS project. Previously, when you made a GraphQL request for something inaccessible, the response simply showed a lack of data, but without explicitly hiding any related fields:

{
  "data": {
    "blackFridayOffer": null
  }
}

Sure, no data is spilling out, but the mere existence of the blackFridayOffer field in the project's schema is a subtle hint that there's some Black Friday intel lurking about, potentially even a per-order discount. That could be information you'd rather keep under wraps.

The Solution

As of today, all new DatoCMS projects will ensure enhanced security by implementing a new behavior. If an API token can only access specific models, inaccessible GraphQL fields will be completely hidden from the GraphQL schema and response, eliminating any potential information exposure.

The same query would result in an error:

{
  "errors": [
    {
      "message": "Field 'blackFridayOffer' doesn't exist on type 'Query'",
      "path": [
        "query",
        "blackFridayOffer"
      ]
    }
  ]
}

By concealing the inaccessible field, the response no longer reveals any information about the Black Friday offer, safeguarding against potential data exposure risks.

Migrating Existing Projects

If you have an existing project that you'd like to update, you can easily do so from the "Available Updates" section of your environment configuration, as shown in this video:

We strongly recommend testing the effects in a sandbox environment before applying the change to your primary environment, as this update cannot be undone.

We've introduced two user-friendly features that will enhance your experience with DatoCMS, offering increased customization without added complexity.

In Edit SEO field > Presentation you will find two more options:

SEO Fields Customization

Choose precisely which fields to display to your editors, giving you the flexibility to focus on what matters most. Choose the fields custom combination of title, description, image, noindex and X summary card:

Example of what "noindex" looks like to editors:

Social Link Previews Selection

With our latest update, you can now handpick the social link previews that matter most to your editors, by selecting which previews to display in the SEO field.

In addition to the pre-existing previews for Google Search, Twitter (X), and Facebook, we are also introducing three new previews: WhatsApp, Telegram, and Slack:

Example of the resulting social media card previews for editors:

We noticed that some users were using custom-made fields to be able to manage robots meta tags preferences at a record level. That is why we decided to introduce it as an enhancement to our SEO field functionality.

Before, you could only set indexing at an environment level, in the SEO Preferences. Recognizing that some scenarios demand more flexibility, we've implemented a "Prevent a page from being indexed by search engines" option also for single records.

This checkbox, available in all SEO fields, empowers developers to seamlessly add a Robots noindex meta tag to pages, offering a nuanced solution for cases not covered by our pre-existing options.

Our CDA _seoMetaTags will return a new Robots noindex attribute if noIndex is enabled either at environment level or record level. Read more about _seoMetaTags, on our CDA documentation.

In an attempt to enhance the discoverability of the diverse editors available for each field type, we've just rolled out a minor visual tweak to the field editing form.

Now, for all the various editor types that Dato natively offers for each field, there's a small illustration that exemplifies the final result on the content editing side:

In case a plugin that has been installed adds extra editor types, these will be shown in the user interface with a universal Plugin icon:

In future versions of the Plugin SDK we might allow customization of the illustration associated with each field editor... but one thing at a time! 😉

We understand the importance of safeguarding critical environments, and based on valuable feedback from our users, we're introducing a significant enhancement.

With the addition of the new flag "Force the use of sandbox environments" under Project settings > Global properties, admins now have the option block any change to the schema and configuration of the primary environment:

Developers can now work confidently, knowing that destructive actions are disabled, while users still retain the ability to navigate and edit content in the Content and Media Area tabs.

Activating this feature enforces best practices such as migration scripts and sandbox environments, minimizing the likelihood of unintentional changes or footgun situations in production.

After receiving feedback from our customers, we have decided to make improvements to our translation approach.

Currently, the entire CMS interface is translated into 15 different languages. However, upon reflection, we realized that this may not have brought significant benefits; in fact, it might have posed some inconveniences.

Our developers' documentation is only provided in English, which means that the DatoCMS glossary and terminology specific to our domain is expressed in English. If the localization settings in the CMS are different, developers may struggle to follow our docs, and find the same entries in the CMS interface.

We also know for a fact that developers are fairly comfortable with English, and translations primarily benefit content writers and editors, who may feel disoriented with English.

As a result, we have chosen to maintain the sections of the app that can only be accessed by developers exclusively in the English language. This includes the Schema, CDA Playground, and Project Settings tabs.

The translation work will also be much easier with the significant decrease in the number of strings to be translated. Our translation process for DatoCMS relies on our wonderful community of users, so if you would like to help us by improving existing translations in your language or suggesting additional ones, please contact us via email. We provide €500 in platform credits for a complete localization.

A slug field previously needed a mandatory string field as its reference field. However, from today onward, slug fields no longer enforce this requirement.

No changes have been made to existing slug fields.

The schema UI will continue to suggest using a reference field because it is the most common option, but you now have the ability to uncheck the validation:

A simple but very welcome validation just landed for Single-asset, Asset Gallery and SEO and Social fields: the ability to require a specific aspect ratio for the uploaded images:

By enforcing a specific aspect ratio, you can ensure that all images displayed have a uniform appearance, thus maintaining consistency and aesthetics in the presentation of assets on your website or platform.

We're delighted to announce the release of an improved navigation system inside DatoCMS projects. It offers the same simplicity you are familiar with, but with an improved user experience.

Here are the main changes:

✅ The new Project Settings area lists all the global settings

✅ Environment-specific configuration happens in the Configuration tab

✅ Models and blocks are now under the Schema tab

This result comes from our commitment to continuous improvement: it is just the beginning of larger changes, always guided by user testing sessions and your precious feedback.

We are excited to announce the public beta release of one of our most requested features: Deep Filtering!

Deep Filtering enables the Content Delivery API to filter records based on the content within their blocks. This functionality is supported in both Modular Content and Structured Text fields.

To learn how to activate deep filtering, and learn everything about the filtering options it enables, please refer to its documentation page.