<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:webfeeds="http://webfeeds.org/rss/1.0">
  <channel>
    <title>Guido Flohr - #Security</title>
    <description></description>
    <link>https://www.guido-flohr.net/</link>
    <webfeeds:cover image="http://www.guido-flohr.net/assets/images/gfl-profile.jpeg" />
    <atom:link href="https://www.guido-flohr.net/" rel="self" type="application/rss+xml"/>

    <pubDate>Tue, 02 Jun 2026 17:07:24 +0000</pubDate>
    <lastBuildDate>Tue, 02 Jun 2026 17:07:24 +0000</lastBuildDate>
    <generator>Qgoda vv0.11.0 (https://www.qgoda.net/)</generator>
      
      <item>
        <title>Authenticating Access to Private Content Hosted with AWS CloudFront</title>
        <description>&lt;img src="/assets/images/authenticating-access-to-private-content-hosted-with-aws-cloudfront/metal-padlock-on-keyboard.jpeg" width="100%"&gt;Setting up a static website, uploading it into an S3 bucket that serves as the origin of a CloudFront distribution is a simple and cheap solution. But what if you want to control access to the content? HTTP basic authentication no longer seems to work and is clumsy and ugly anyways. But signed cookies give you a better solution at hand and it is easy to implement with serverless computing.</description>
        <pubDate>Wed, 06 Mar 2024 22:00:00 +0000</pubDate>
        <link>https://www.guido-flohr.net/authenticating-access-to-private-content-hosted-with-aws-cloudfront/index.html</link>
        <guid isPermaLink="true">https://www.guido-flohr.net/authenticating-access-to-private-content-hosted-with-aws-cloudfront/index.html</guid>
        
        <category>Web</category>
        
        <category>Security</category>
        
        <category>AWS</category>
        
        <category>CloudFront</category>
        
        <category>Lambda</category>
        
        <category>S3</category>
        
        <category>JavaScript</category>
        
        
        <category>Development</category>
        
        <category>System Administration</category>
        
      </item>
      
      <item>
        <title>How to Use Saved Passwords Everywhere</title>
        <description>&lt;img src="/assets/images/how-to-use-saved-passwords-everywhere/post-it-password.jpeg" width="100%"&gt;Some web sites and applications prevent users from using previously saved credentials. There a very few legitimate reasons to do so. In the vast majority of cases, such measures just patronize users, often those people that actually keep up the service with their financial support. But it is actually quite simple to bypass such paranoid settings.</description>
        <pubDate>Mon, 11 Feb 2019 22:00:00 +0000</pubDate>
        <link>https://www.guido-flohr.net/how-to-use-saved-passwords-everywhere/index.html</link>
        <guid isPermaLink="true">https://www.guido-flohr.net/how-to-use-saved-passwords-everywhere/index.html</guid>
        
        <category>Security</category>
        
        <category>Passwords</category>
        
        
        <category>System Administration</category>
        
      </item>
      
      <item>
        <title>How To Use Google Maps API Keys For Free</title>
        <description>&lt;img src="/assets/images/how-to-use-google-maps-api-keys-for-free/stolen-key.jpeg" width="100%"&gt;The use of a Google API Key can be restricted to a configurable set of host or domain names. But does this protect (ab)use of the key by others? Not really.</description>
        <pubDate>Mon, 14 Oct 2019 21:00:00 +0000</pubDate>
        <link>https://www.guido-flohr.net/how-to-use-google-maps-api-keys-for-free/index.html</link>
        <guid isPermaLink="true">https://www.guido-flohr.net/how-to-use-google-maps-api-keys-for-free/index.html</guid>
        
        <category>JavaScript</category>
        
        <category>Development</category>
        
        <category>Security</category>
        
        
        <category>Development</category>
        
      </item>
      
  </channel>
</rss>
