Skip watching entire videos - get the full transcript, search for keywords, and copy with one click.
Share:
Video Transcript
Video Summary
Summary
Core Theme
Content Security Policy (CSP) is a browser-enforced security layer that helps protect web applications, especially those exposed to the internet, from various attacks like cross-site scripting (XSS) and clickjacking by controlling the sources from which content can be loaded and executed.
Mind Map
Click to expand
Click to explore the full interactive mind map • Zoom, pan, and navigate
Everyone, we'll be
starting soon.
Just wait for
few more minutes to see if everyone else
has joined.
[Music]
Hey guys. Um, we'll be it's time for the
workshop. So let's do the workshop on
content security policy.
Um we're also live on YouTube. So
there's uh
Um in this one I'm going to talk about
content security policies and the Mandix
application. So
this one mainly
um assign or this is mainly useful if
there is and it's if it's not an
internal application basically right if
your application is open to the to the
world on the internet then you would
want content security policy to be
implemented on your website. Um
so what is content security policy?
Basically, it's something that is
u it's a browser enforced security
layer. So, you tell the browser uh what
scripts can run on your computer. If you
want any inline scripts to be running or
not, um what should be the sources? For
example, if you're loading iframes into
your website, then what what external
domains can load iframes on your on your
website or not? If someone wants to load
your website as an iframe on their
website then do you allow that or not
and if you allow then what domains what
domains do you allow and all those
things right um you can block
inline scripting inline styling as well
u those things help with cross-ite
scripting attacks and clickjing and all
those things so it's it's really simple
um once you understand how the whole
thing works you just have to insert your
your CSP into into the header of your
application in index.html or through the
Mendix cloud. And once you do that, all
all you need to do from from there
onwards would be would be to um would
the let the browser do its do its thing. So
So
for example,
if you look at this u this first right
uh say it's a Mendix form where you can
use uh it's a text type field and
someone can add the name right now
someone if someone is doing a cross-
site attack then they could always put
put a inline script and and do something
in it or um
um
without CSP they could add add this one
line of script as well. But when you
have CSP
um configured in your application you
would you would get an error like this
in your browser console where it says
inline scripting uh is not allowed
violates CSP directive.
So in Mendix there are uh there's three
ways to to integrate CSP in your
application. I always recommend the
first approach only which is through the
u runtime configuration in your in your
Mendix cloud if you're using Mendix
cloud but if you're not using Mendix
cloud then you would go with the other
options. So which is go to development
portal and your environment details and
then and then those steps over there. So
um and local is you add through a meta
tag in your index.html
and the third option is through a Java
action. So but
but
so what types of of things you can
control right there's a so every control
is called a directive
um for example if you do default source
as none so it's a it means you will not
let anything except your own app to be
to be running or you would not let any
execution that is outside your domain.
Um but then there comes the other other
directives as well which which will
override something you have in default.
So say default is set to none but you're
allowing scripts to be executed from
self which mean your own domain then
that would be allowed because the
individual directive takes higher
precedence over the default directive.
But say you had only default and script
right then everything else would be
considered as none because you don't
have other directives defined. So it'll
go to go to the default one only and
and
and there there are different directives
right? So one is for style, one is for
so no inline styling which is
you'll always have to allow
inline styling with Mendix because
that's how the Atlas UI is built where
you cannot say if you if you say um
inline styling and only self then it'll
break your Mendix application or the UI
in your Mendix application. Um
Um
so all the special keywords that I was
talking like unsafe inline um and there
are many other and none self all these
are special keywords which needs to go
in single quotes. If you put it without
single quotes then sorry then it will
give you an error.
So for examples if you're doing script
as online without quotes then it will
give you error but this one will not
give you an error. Um,
Um,
and like I mentioned the Atlas UI
challenge. If you Atlas UI already does
so much inline styling that if you start
putting unsafe inline
um sorry if you don't put unsafe inline
it means inline styling will not be
allowed right and that will break the UI
for everything in atlas that has that
has inline styling. Um so to overcome
this you have basically three options.
one is um to allow in safe inline or
create hash for for every inline styling
which is a lot of tedious work or
refactor atlas UI which also we don't
want to do so the best option and
because styling are not are generally
very safe to allow inline um I would say
just go with the option one to allow
But
never allow inline scripts or do not put
the do not use the keyword unsafe inline
for script sources because then anyone
could inject
JavaScript or into your application and
then it it is prone to again
cross-cripting attacks. So if if you
want to if say for example there's no
way for you to execute
JavaScript through a file in your
application and you have to have inline
uh inline JavaScript then there's two
options which is um create create a bind
uh create a simple nons for your for
your script tags and then use that. So
for example, you say script source and
nons random 1 to three, right? And when
you're creating this this one script,
you add the same nons. So any script tag
that has the nons mentioned over here
and in your security policy,
that script tag will be allowed for
inline execution. Um,
and the ones that don't have will not be
allowed. But we also have to make sure
that these are these are unique. If you
start repeating then the browser won't allow
allow u.
u.
And the second way to do it would be
would be through hashes. So copy your
copy your um
uh JavaScript code into into say a
terminal or command from and create a
hash for it. Once you create a hash for
it, um you can do inline scripting with
it and in your CSP you just have to put
a script source and hash like this. You
don't have to put that same hash as a
nons in your script tags. But the thing
you have to be very careful about is
every white space can can break your um
your sorry it cannot it will break but
every everything will change your hash
right so your your hash will stop
working. So
if you even add an extra space basically
when creating the hash
um and once once you want to start
implementing CSP in your application
um the general recommendation is to
start with giving all the permissions
right so that your used to your
application having CSP and then you
slowly u start tightening it I like it
the other way where make it strict and
then based on the errors you see you
keep relaxing. So uh but the this is the
most common approach that people take
where they start with everything that
they know of um and then they slowly
start to tighten and tighten and relax
as they see errors. Um,
Um, so
if you say
if you add a CSP
in your
in your Mendix application uh or through
the through the cloud portal and this is
our typical if this is how your typical
index.html HTML or or any of the pages
are then all those would start getting
blocked by CSP if you have a stricter
CSP. So for example, if you're not
allowing inline scripting, um
um
one of the compliant men configuration
that you could use is like
default is only source script is also
only source and then a few nons and and
then if you have any external domains
that you're allowing to run scripts from
basically if you're if you're
integrating any third party SDKs for say
analytics or or any any SDK
integrations, right? A lot of financing
or finance applications use it basically to
to
um to say integrate any third party uh
services. So the same for same goes for
connect and source and and other things.
Frame ancestors none basically means
that you're not allowing your website to
be a part of I frame in any other
application which is which is how it
should be. Um
and then there are the way to test your
CSP is basically once you start loading
things. Um and you can just go to
browser console and in the errors pane
it'll start showing if there's something
that you're blocking which you want to
allow. Right? So this could be a valid
one but you forgot to unblock it in your
CSP. So once you're testing the
application, you will see the errors
roll up in your uh in your browser
console and you can go ahead and fix
them in the next deployment as well.
Um, if you're doing in Chrome, Chrome
even suggest the hash. So you don't have
to go and run a command to get the hash
value saying this is the hash I you
and then there's something that is
report only mode which is also good. So
if you just want to say uh the first
time you you're implementing uh security
policy in your production application
and you don't want your your brow your
users to be blocked by anything. There
is a report only mode which is also
really good. So you do report only mode
and and put a default source as self. So
anything outside itself would be
throwing an error in the browser console
and but your users will not get blocked
from using it. The advantage and then
the second one is you can get a report
URI so and make an endpoint or a page
where or make an endpoint where where
the browser will go and push the or
submit the errors. So that way you are
making a repository of of all the things
that are that should be allowed or or at
least anything that throws error and
then you can audit and allow the things
that you seem necessary. Um
Um and
and
so this is how the the violation would
be sent as a JSON. Uh the page you found
the error on what was what was what
errored out. So script source basically
errored out for self um if any URI that
was blocked that will show up um and
what line number and what's the source
file so you get a lot of lot of
information you could do that through a
JavaScript listener as well but if you
have an endpoint where the browser could
go log all the all the errors that would
And some of the common pitfalls as we
discussed is not using
uh not using the single quotes on the
special keywords. Um there are many
marketplace widgets that would fail
because they would be using a library in
the background which you're not allowed.
So for example for the chart widget it
uses gs deliver.net. So if you're not
allowed this particular library in your
script source then the charts widget
would start failing or it will not
render any charts. um the
the
again the frame ancestors so
so
it's best to put the whole URL you
cannot put self over here because your website
website
this frame ancestors will be will be
used in when your website is loading an
iframe in some other website right so
you cannot use self over there that's
why if you want to allow any website to
um it could be your internal website
right you where you want one Mendix
application to show a page from another
application as a as an iframe. So if you
want to allow then you'll have to put
the exact URL and self is not allowed here.
I would show one example of um
So if you see this one has frame
ancestors for self. So you can hold you
can I frame W3 schools inside W3schools
or mycourses.w3schools.com
or pathfinder.w3school.
So they allowed two of their subdomain.
um to be able to iframew3schools.com.
But say if you go to uh
if you do Google then
um it has it has nothing for for frame
ancestors which means it'll it will not allow.
allow. Yes.
Yes.
So um that's how frame ancestors would work
so
there there is a lot of um
this is
so some some some browsers do use nons
and some don't don't use nons. uh
there's a brief time when in one of
these CSP they stopped using nons and
then they allowed it again. So in the in
the most recent browsers which uses uh
CSP level three I think they that allows
knots. So we should be fine with that. and
and
um some of the mending specific best
practices that we have used a lot is
is uh restrict default to false so that
by default if you if you miss something
in rest of the directives you're not
allowing some random website because you
don't want to put cdn.x.com index.com as
part of default, right? Um because that
might be doing adding some scripts only
and you don't want
or or you don't want like frame
ancestors to be to be part of or
cdn.x.com to be part of frame ancestors
if you missed adding them over here. So
So um
just making sure I did not miss anything.
But yeah, so if you want to start doing
implementing CSP in your applications,
the first step I would I would recommend
doing is to go report only mode. so that
you start catching every every CSP
errors from your production environment
or UAT environment. Um and then analyze
all the violations and add the
legitimate sources only and then start
testing with actual users in production
or if you're testing like strict
uh strict modes then I would do a lot of
testing in UAT before pushing it to
production um or even pre-pro environments.
environments.
And then go to um again your enforcement
mode which is content security policy
without the report only mode.
And and then based on the reports that
you get you can do monitor and do minor refinements.
Um
let's see the first one if anyone is
is
okay should be simple
simple
but yeah for this for the CSP it's it's
not a complicated topic Um but it's a
really important topic. Um and this is
not something you need to do on a
day-to-day basis in your application,
but it is something that needs to be
done at least to start with, right? Um
and honestly, this is not only for
Mendix applications, but it is for any
any front-end applications, any any
application that's open to the world out there.
there.
So yeah, I would start today with report
only mode to start catching all the CSP
errors that that you should be throwing
or you should not be allowing. And then
um and then these are just the things
that you shouldn't forget that we
already discussed. Um
yeah, most of the content that I
mentioned is available on
the Mendix docs as well and content
security policy.com. Um
Um
yeah. So so that's uh that's CS that's
about about CSP. Let me know if you guys
and no in the numeric it doesn't we have
>> specified that means everything is
>> everything is blocked
>> is blocked
um yeah none means it blocks everything
and self means everything is allowed
So if we want to
be in another
another >> Mhm.
>> Mhm.
>> you have to specify an >> Yes.
>> Yes.
>> Without the
>> without the quotes.
>> Yes. Quotes is only for the the special keywords.
keywords.
>> Yeah. So
So all the special key the five special
keywords here only those need to have quotes
and we can always
I use different tools to evaluate CSP um
or what other websites are using but you
can see what this is what googlec has Um,
cP. [Music]
So these guys have a huge list of of um
of scripts that they allow from, right?
So because they're using Google Tag
Manager, Google Analytics, um they're
allowing those things, right? They want
to they're loading all their JavaScripts
through or a lot of their JavaScript
through assets dot CSPR as well. You
could also do
um say if you if you have multiple
domains and if all are your internal
domains, you could also do uh star.csper.io,
right? So for example, if you if you
know that you want to allow
a lot of resources to be loaded from
from your own domain, then what I would
also do is because it's my own domain
and I find it safe, what I would also do
is default source self and then I would
do uh star.mmy domain.com,
right? Because I have a lot of
applications that talk to one another,
then it I would consider that to be
safe. But again you you take that
decision on your personal evaluation.
>> So the way to do that is actually
manually index
>> index or html. There's also um
if you go to the
So if you go to how to um CSP on Mendix,
there's also steps on
on how to do it in the in the index or
yeah, so if you're using a dojo cl,
so this is how you do it in a React
client in app setup.js,
right? But if you're still using uh a
dojo then you do it in index.html
or okay they also want you to do in app
setup. That's fine then. But yeah, you
do it from these two places
But the the best way that I recommend to
do it is
is either the either
either
through the Mendix runtime or runtime configuration
configuration
or through a Java action um
>> yes so but then
that's correct and are your apps client
facing also open to the internet
If it's only internal applications for
Let's see if anyone on the live stream
has any questions. Um,
Um,
where do we check if there's any
I cannot find any questions here. So, I
Click on any text or timestamp to jump to that moment in the video
Share:
Most transcripts ready in under 5 seconds
One-Click Copy125+ LanguagesSearch ContentJump to Timestamps
Paste YouTube URL
Enter any YouTube video link to get the full transcript
Transcript Extraction Form
Most transcripts ready in under 5 seconds
Get Our Chrome Extension
Get transcripts instantly without leaving YouTube. Install our Chrome extension for one-click access to any video's transcript directly on the watch page.
