GraphQl public catalog endpoints expose some data that should not be visible

[rogyar]

Preconditions (*)

1. Magento installation with CatalogGraphQl module enabled

Steps to reproduce (*)

Take a look at the ProductInterface

It allows retrieving some data for the non-authorized users that we usually expose neither on the standard storefront nor with the REST API.

For example, the following fields

• special_from_date
• special_to_date

are not supposed to be visible for a non-authorized client since this data exposes information about sales period that should be hidden by default.

The same about

• created_at
• updated_at
• websites
• attribute_set_id

Expected result (*)

1. Only data that is required for rendering product details on the storefront is available

Actual result (*)

1. Product data that is supposed to be visible for admin only is visible for non-authorized users

Proposed solution

At least, remove the following fields from the schema

• special_from_date
• special_to_date

The other fields mentioned in the issue need to be discussed

---

• Severity: S0 - Affects critical data or functionality and leaves users without workaround.
• Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
• Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
• Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
• Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.

[m2-assistant]

Hi @rogyar. Thank you for your report.
To help us process this issue please make sure that you provided the following information:

• Summary of the issue
• Information on your environment
• Steps to reproduce
• Expected and actual results

Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:

@magento give me 2.4-develop instance - upcoming 2.4.x release

For more details, please, review the Magento Contributor Assistant documentation.

Please, add a comment to assign the issue: @magento I am working on this

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

⚠️ According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.

🕙 You can find the schedule on the Magento Community Calendar page.

📞 The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, please join the Community Contributions Triage session to discuss the appropriate ticket.

🎥 You can find the recording of the previous Community Contributions Triage on the Magento Youtube Channel

✏️ Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel

[misha-kotov]

Agree with these as well:

• created_at
• updated_at
• websites
• attribute_set_id

But if we remove them, will need to make sure sorting in categories still works (ex: if the category products are sorted by updated_at or created_at

[cpartica]

I can see a case where you have a "promotion" of a price and you want to say until when it's available: "1 day left"
It is true that created_at, updated_at shouldn't be there
Also attribute_set_id if we don't have a use case for it we can remove it.

The problem is that removing fields is backward incompatible and should be approved.
I can create an architectural proposal and try to get these flushed out

[rogyar]

@cpartica. Thanks for sharing your thoughts, it makes sense.
We may add the possibility to see the special_to_date. But my point is GraphQL will be the only way to get this information without authorization. So, for existing stores, it means that if the merchant wants to keep this information publicly hidden (current behavior with the standard storefront) he needs to customize the system behavior.

As for the architectural proposal, If you could create that, it would be great. Thanks!

[mauragcyrus]

@rogyar could you please link the PR?

[andrewbess]

@magento I'm working on it