Clarify the description of REST vs OCS in accordance to sugestions discussed

developer_manual/basics/controllers.rst

@@ -393,6 +393,10 @@ A :doc:`template <front-end/templates>` can be rendered by returning a TemplateR
 
     }
 
+Showing a template is the only exception to the rule to :ref:`not disable CSRF checks <csrf_introduction>`:
+The user might type the URL directly (or use a browser bookmark or similar) to navigate to a HTML template.
+Therefore, usage of the ``#[NoCSRFRequired]`` attribute (see :ref:`below<controller_authentication>`) is acceptable in this context.
+
 Public page templates
 ^^^^^^^^^^^^^^^^^^^^^
 
@@ -434,6 +438,9 @@ A ``OCP\\AppFramework\\Http\\Template\\SimpleMenuAction`` will be a link with an
 developers can implement their own types of menu renderings by adding a custom
 class implementing the ``OCP\\AppFramework\\Http\\Template\\IMenuAction`` interface.
 
+As the public template is also some HTML template, the same argumentation as for :ref:`regular templates<controller_template>` regarding the CSRF checks hold true:
+The usage of ``#[NoCSRFRequired]`` for public pages is considered acceptable and is actually needed to visit the page without an active account.
+
 Data-based responses
 --------------------
 
@@ -448,10 +455,14 @@ The user only indirectly requested the data by user interaction with the fronten
 OCS
 ^^^
 
+In order to simplify exchange of data between the Nextcloud backend and any client (be it the web frontend or whatever else), the OCS API has been introduced.
+Here, JSON and XML responders have been prepared and are installed without additional effort.
+
 .. note::
-    This is purely for compatibility reasons. If you are planning to offer an external API, go for a :ref:`REST APIs <rest-apis>` instead.
+    The usage of OCS is closely related to the usage of :doc:`../digging_deeper/rest_apis`.
+    Unless you have a clear use-case, it is advised to use OCS over pure REST.
+    A more detailed description can be found in :ref:`ocs-vs-rest`.
 
-In order to simplify exchange of data between the Nextcloud backend and any client (be it the web frontend or whatever else), the OCS API has been introduced.
 To use OCS in your API you can use the **OCP\\AppFramework\\OCSController** base class and return your data in the form of a **DataResponse** in the following way:
 
 .. code-block:: php
@@ -509,6 +520,10 @@ Now your method will be reachable via ``<server>/ocs/v2.php/apps/<APPNAME>/api/v
 JSON
 ^^^^
 
+.. warning::
+    The usage of standard controller to access content data like JSON (no HTML) is considered legacy.
+    Better use :ref:`OCS <ocscontroller>` for this type of requests.
+
 Returning JSON is simple, just pass an array to a JSONResponse:
 
 .. code-block:: php
@@ -547,6 +562,11 @@ Because returning JSON is such a common task, there's even a shorter way to do t
 
 Why does this work? Because the dispatcher sees that the controller did not return a subclass of a Response and asks the controller to turn the value into a Response. That's where responders come in.
 
+.. deprecated:: 30
+
+    Usage of classical controllers for data transmission should be avoided. Use OCS instead.
+
+
 Handling errors
 ^^^^^^^^^^^^^^^
 

developer_manual/conf.py

@@ -182,7 +182,7 @@
 #'pointsize': '10pt',
 
 # Additional stuff for the LaTeX preamble.
-'preamble': '\extrafloats{100}\maxdeadcycles=500\DeclareUnicodeCharacter{274C}{\sffamily X}',
+'preamble': '\\extrafloats{100}\\maxdeadcycles=500\\DeclareUnicodeCharacter{274C}{\\sffamily X}',
 }
 
 # Grouping the document tree into LaTeX files. List of tuples

developer_manual/digging_deeper/rest_apis.rst

@@ -6,7 +6,8 @@ REST APIs
 
 .. sectionauthor:: Bernhard Posselt <[email protected]>
 
-Offering a RESTful API is not different from creating a :doc:`route <../basics/routing>` and :doc:`controllers <../basics/controllers>` for the web interface. It is recommended though to inherit from ApiController and add ``#[CORS]`` attribute to the methods so that `web applications will also be able to access the API <https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS>`_.
+Offering a RESTful API is not different from creating a :doc:`route <../basics/routing>` and :doc:`controllers <../basics/controllers>` for the web interface.
+It is recommended though to inherit from ApiController and add **@CORS** annotations to the methods so that `web applications will also be able to access the API <https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS>`_.
 
 .. code-block:: php
 
@@ -44,7 +45,8 @@ CORS also needs a separate URL for the preflighted **OPTIONS** request that can
     )
 
 
-Keep in mind that multiple apps will likely depend on the API interface once it is published and they will move at different speeds to react to changes implemented in the API. Therefore it is recommended to version the API in the URL to not break existing apps when backwards incompatible changes are introduced::
+Keep in mind that multiple apps will likely depend on the API interface once it is published and they will move at different speeds to react to changes implemented in the API.
+Therefore it is recommended to version the API in the URL to not break existing apps when backwards incompatible changes are introduced::
 
     /index.php/apps/myapp/api/1.0/resource
 
@@ -79,3 +81,147 @@ To add an additional method or header or allow less headers, simply pass additio
         }
 
     }
+
+.. _ocs-vs-rest:
+
+Relation of REST and OCS
+------------------------
+
+There is a close relationship between REST APIs and :ref:`OCS <ocscontroller>`.
+Both provide a way to transmit data between the backend of the app in the Nextcloud server and some frontend.
+This is explicitly not about :ref:`HTML template responses <controller_html_responses>`.
+
+State-of-the-Art methods and comparison
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following combinations of attributes might be relevant for various scenarios:
+
+#. Plain frontend route: ``Controller`` class
+#. OCS route: ``OCSController`` class
+#. OCS route with CORS enabled: ``OCSController`` class and ``#[CORS]`` attribute on the method
+
+.. warning::
+  Adding the ``#[NoCRSFRequired]`` attribute imposes a security risk.
+  You should not add this to your controller methods unless you understand the implications and be sure that you absolutely need the attribute.
+  Typically, you can instead use the ``OCS-APIRequest`` header for data requests, instead.
+
+.. warning::
+  Adding the attribute ``#[CORS]`` alone is not sufficient to allow access using CORS with plain frontend routes.
+  Without further measures, the CSRF checker would fail.
+  So, enabling CORS for plain controllers is generally and highly discouraged.
+
+  You would have to disable the CSRF checker (one more security risk) or use the ``OCP-APIRequest`` header to successfully pass the checker.
+  The latter requires dedicated JS code on the importing page.
+
+There are different ways a clients might interact with your APIs.
+These ways depend on your API configuration (what you allow) and on which route the request is finally made.
+
+- *Access from web frontend* means the user is browses the Nextcloud web frontend with a browser.
+- *Access from non-browser* is if the user accesses the resource or page not using the default browser.
+  Thus can be e.g. a script using CURL or an Android app.
+- *Access from external website* means that the user browses some third party web site and data from your Nextcloud server appears.
+  The other website has to embed/load/use images, JSON data, or other resources from a URL pointing to the Nextcloud server, to be able to do this.
+
+.. hint::
+    The discussion here is for data requests only.
+    If you think of controller :ref:`methods serving (HTML) templates <controller_html_responses>`, disabling CSRF is considered fine.
+
+.. list-table:: Comparison of different API types
+    :header-rows: 1
+    :align: center
+
+    * - Description
+      - ``Controller`` class
+      - ``OCSController`` class
+      - ``OCSController`` class & ``CORS`` on method
+    * - URL prefix (relative to server)
+      - ``/apps/<appid>/``
+      - ``/ocs/v2.php/apps/<appid>/``
+      - ``/ocs/v2.php/apps/<appid>/``
+    * - Access from web frontend
+      - yes
+      - yes
+      - yes
+    * - Access from non-browser
+      - partial [#]_
+      - yes
+      - yes
+    * - Access from external website
+      - ---
+      - ---
+      - yes
+    * - Encapsulated data
+      - no
+      - yes (JSON or XML)
+      - yes (JSON or XML)
+
+.. [#] The external app has to satisfy the CSRF checks.
+       That is, you need to have the ``OCS-APIRequest`` HTTP request header set to ``true``.
+       This is only possible for NC 30 onwards, older versions do not respect the header.
+
+Methods from ``Controller`` classes can return ``DataResponse`` objects similar to ``OCSController`` class methods.
+For methods of a ``Controller`` class, the data of this response is sent e.g. as JSON as you provide it.
+Basically, the output is very similar to what ``json_encode`` would do.
+In contrast, the OCS controller will encapsulate the data in an outer shell that provides some more (meta) information.
+For example a status code (similar to the HTTP status code) is transmitted at top level.
+The actual data is transmitted in the ``data`` property.
+
+As a rule of thumb one can conclude that OCS provides a good way to handle most use cases including sufficient security checks.
+The only exception to this is if you want to provide an API for external usage where you have to comply with an externally defined API scheme.
+Here, the encapsulation introduced in OCS and CSRF checks might be in your way.
+
+
+Historical options
+~~~~~~~~~~~~~~~~~~
+
+.. deprecated:: 30
+  The information in this section are mainly for reference purposes. Do not use the approaches in new code.
+
+Before NC server 30 the plain ``Controller`` classes' methods did not respect the ``OCS-APIRequest`` header.
+Thus, to provide access to this type of controller methods for external apps, it was necessary to use the ``#[NoCSRFRequired]`` attribute (or the corresponding ``@NoCSRFRequired`` annotation).
+
+The following combinations of attributes were relevant for various scenarios:
+
+#. Plain frontend route: ``Controller`` class
+#. Plain frontend with CRSF checks disabled: ``Controller`` class and ``#[NoCSRFRequired]`` attribute on the method
+#. Plain frontend route with CORS enabled: ``Controller`` class and ``#[CORS]`` and ``#[NoCSRFRequired]`` attributes on the route
+#. OCS route: ``OCSController`` class
+#. OCS route with CORS enabled: ``OCSController`` class and ``#[CORS]`` attribute on the method
+
+.. hint::
+  The two scenarios involving the ``OCSController`` have not changed and, thus, the state-of-the-art documentation as noted above still holds true.
+  Thus, these options are not reconsidered here again for simplicity reasons and to get the overall view more crisp.
+
+  The warnings about not using ``NoCSRFRequired`` and ``CORS`` as mentioned in the state-of-the-art section holds true here as well.
+
+.. list-table:: Comparison of different API types
+    :header-rows: 1
+    :align: center
+
+    * - | Description
+      - | ``Controller`` class
+      - | ``Controller`` class with
+        | ``NoCSRFRequired`` on method
+      - | ``Controller`` class with
+        | ``NoCSRFRequired`` and ``CORS``
+        | on method
+    * - URL prefix (relative to server)
+      - ``/apps/<appid>/``
+      - ``/apps/<appid>/``
+      - ``/apps/<appid>/``
+    * - Access from web frontend
+      - yes
+      - yes (CSRF risk)
+      - yes (CSRF risk)
+    * - Access from non-browser
+      - ---
+      - yes
+      - yes
+    * - Access from external website
+      - ---
+      - ---
+      - yes
+    * - Encapsulated data
+      - no
+      - no
+      - no

developer_manual/prologue/security.rst

@@ -213,10 +213,12 @@ Sensitive data exposure
 
 Always store user data or configuration files in safe locations, e.g. **nextcloud/data/** and not in the webroot where they can be accessed by anyone using a web browser.
 
+.. _csrf_introduction:
+
 Cross site request forgery
 --------------------------
 
-Using `CSRF <https://en.wikipedia.org/wiki/Cross-site_request_forgery>`_ one can trick a user into executing a request that they did not want to make. Thus every POST and GET request needs to be protected against it. The only places where no CSRF checks are needed are in the main template, which is rendering the application, or in externally callable interfaces.
+Using `CSRF <https://en.wikipedia.org/wiki/Cross-site_request_forgery>`_ (see also on `MDN <https://developer.mozilla.org/en-US/docs/Glossary/CSRF>`__) one can trick a user into executing a request that they did not want to make. Thus every POST and GET request needs to be protected against it. The only places where no CSRF checks are needed are in the main template, which is rendering the application, or in externally callable interfaces.
 
 .. note:: Submitting a form is also a POST/GET request!
 
@@ -227,7 +229,11 @@ To prevent CSRF in an app, be sure to call the following method at the top of al
   <?php
   OCP\JSON::callCheck();
 
-If you are using the App Framework, every controller method is automatically checked for CSRF unless you explicitly exclude it by setting the ``#[NoCSRFRequired]`` attribute or ``@NoCSRFRequired`` annotation before the controller method, see :doc:`../basics/controllers`
+If you are using the App Framework, every controller method is automatically checked for CSRF unless you explicitly exclude it by setting the ``#[NoCSRFRequired]`` attribute or ``@NoCSRFRequired`` annotation before the controller method, see :doc:`../basics/controllers`.
+
+Additionally, it is advised to carefully select the HTTP method used for requests.
+Requests of type ``GET`` should not alter data but just read existing data.
+As long as no other attack is involved, any non-``GET`` request requires at least user interaction (transmitting a form).
 
 Unvalidated redirects
 ---------------------
@@ -250,6 +256,28 @@ Always validate the URL before redirecting if the requested URL is on the same d
   <?php
   header('Location: https://example.com'. $_GET['redirectURL']);
 
+
+CORS
+----
+
+`Cross-origin resource sharing (CORS) <https://en.wikipedia.org/wiki/Cross-origin_resource_sharing>`_ (see also on `MDN <https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS>`__) is a method implemented by browser to access resources from different domains at the same time.
+Assume, there is a website published on host A.
+The URL would for example be https://A/path/to/index.html.
+If there is a _different_ host B that serves a resource (e.g. an image file) as https://B/assets/image.jpg, the index file on host A could simply link to the image on B.
+However, to protect B and its property (the image), the browsers do not silently embed the image of B into the page of A.
+Instead, B is kindly asked by the browser if embedding is allowed (the so-called `preflight <https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request>`_).
+
+To do so, there is a first request made to the resource on B with the ``OPTIONS`` HTTP command/verb.
+The server only answers with the headers as specified and adds ``Access-Control-*`` headers.
+These define, what the browser is to be allowed to do.
+Only if the destination server B confirms cross site resource sharing is allowed, the browser access the resource.
+
+Basically, accessing foreign resources is not limited to embedding images.
+Using JavaScript, arbitrary XHR/Ajax requests can be directed at arbitrary other hosts.
+There are some safety measurements in place (especially about cookie handling), but one has still to be careful not to leak information unwillingly.
+Especially, if the destination server B allows to sent credentials using ``Access-Control-Allow-Credentials: true``, cross site scripting is very critical.
+You need :ref:`CSRF protection <csrf_introduction>` in place or your users are at relatively high risk.
+
 Getting help
 ------------